From report at bugs.python.org  Sat May  1 00:26:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Apr 2010 22:26:33 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272664752.48.0.966034556849.issue8566@psf.upfronthosting.co.za>
Message-ID: <u2x1afaf6161004301526l6462ae0csd8e7f2acbc7fccb3@mail.gmail.com>


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

2010/4/30 Jeffrey Yasskin <report at bugs.python.org>:
>
> Jeffrey Yasskin <jyasskin at gmail.com> added the comment:
>
> In what way will my patch break test_parser on Windows? I preserved the behavior of re-opening the file in text mode after determining the encoding. Do I need to add 'U' to open()'s mode string?

Sorry, my mind was in other Python versions. It looks fine.

----------

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

From report at bugs.python.org  Sat May  1 00:45:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 22:45:51 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272667551.39.0.890192202517.issue8533@psf.upfronthosting.co.za>


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

regrtest_traceback_stderr.patch	is not enough: support._run_suite() writes output to sys.stdout instead of sys.stderr. New version of the patch fixes that.

----------
Added file: http://bugs.python.org/file17152/regrtest_traceback_stderr-2.patch

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

From report at bugs.python.org  Sat May  1 00:45:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 22:45:56 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272667556.76.2.82516525333e-05.issue8533@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17093/regrtest_traceback_stderr.patch

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

From report at bugs.python.org  Sat May  1 00:57:29 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Fri, 30 Apr 2010 22:57:29 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>


New submission from Dmitry Chichkov <dchichkov at gmail.com>:

The namespace_separator parameter is hard coded in the cElementTree.XMLParser class disallowing the option of ignoring XML Namespaces with cElementTree library.

Here's the code example:
 from xml.etree.cElementTree import iterparse
 from StringIO import StringIO
 xml = """<root xmlns="http://www.very_long_url.com"><child/></root>"""
 for event, elem in iterparse(StringIO(xml)): print event, elem

It produces:
 end <Element '{http://www.very_long_url.com}child' at 0xb7ddfa58>
 end <Element '{http://www.very_long_url.com}root' at 0xb7ddfa40> 

In the current implementation local tags get forcibly concatenated with URIs often resulting in the ugly code on the user's side and performance degradation (at least due to extra concatenations and extra lengthy compare operations in the elements matching code).

Internally cElementTree uses EXPAT parser, which is doing namespace processing only optionally, enabled by providing a value for namespace_separator argument. This argument is hard-coded in the cElementTree: 
 self->parser = EXPAT(ParserCreate_MM)(encoding, &memory_handler, "}");

Well, attached is a patch exposing this parameter in the cElementTree.XMLParser() arguments. This parameter is optional and the default behavior should be unchanged.  Here's the test code:

import cElementTree

x = """<root xmlns="http://www.very_long_url.com"><child>text</child></root>"""

parser = cElementTree.XMLParser()
parser.feed(x)
elem = parser.close()
print elem

parser = cElementTree.XMLParser(namespace_separator="}")
parser.feed(x)
elem = parser.close()
print elem

parser = cElementTree.XMLParser(namespace_separator=None)
parser.feed(x)
elem = parser.close()
print elem

The resulting output:
<Element '{http://www.very_long_url.com}root' at 0xb7e885f0>
<Element '{http://www.very_long_url.com}root' at 0xb7e88608>
<Element 'root' at 0xb7e88458>

----------
components: Library (Lib)
messages: 104671
nosy: dmtr
priority: normal
severity: normal
status: open
title: Hardcoded namespace_separator in the cElementTree.XMLParser
type: performance
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat May  1 01:00:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 23:00:52 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272668452.18.0.354524187604.issue8583@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +flox

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

From report at bugs.python.org  Sat May  1 01:02:12 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Fri, 30 Apr 2010 23:02:12 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272668532.32.0.30453333452.issue8583@psf.upfronthosting.co.za>


Changes by Dmitry Chichkov <dchichkov at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17153/issue-8583.patch

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

From report at bugs.python.org  Sat May  1 01:03:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Apr 2010 23:03:51 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272668631.49.0.450830638783.issue8514@psf.upfronthosting.co.za>


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

Ok, here is a first version of my patch to implement os.environb:
 - os.environb is the bytes version of os.environ, both are synchronized
 - os.environ(b).data stores bytes keys and values on POSIX (but unicode on Windows)
 - create os.getenvb()->bytes
 - os.environb and os.getenvb() are not available on Windows nor OS/2
 - os.environ(b) et os.getenv(b)() accept both byte and unicode keys: that's maybe a stupid idea, I don't know yet :-)
 - fix #8513: subprocess: support bytes program name on POSIX
 - create os.fsencode() and os.fsdecode()

The patch is not done (the documentation should be updated), but it's a new step to help the discussion. I didn't tried it on Windows.

I already try twice to write os.environb some months ago, but I failed (it was too complex for me). os.environ and os.environb now share the same "data" dictionary, and their methods converts inputs and outputs if necessary.

----------
Added file: http://bugs.python.org/file17154/issue8514.patch

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

From report at bugs.python.org  Sat May  1 01:05:01 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 30 Apr 2010 23:05:01 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272668701.74.0.971370662284.issue8566@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Thanks. Committed as r80668. May I update http://python.org/dev/peps/pep-0291/ to reflect that 2to3 should continue working on python-2.5?

----------

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

From report at bugs.python.org  Sat May  1 01:09:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Apr 2010 23:09:58 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272668701.74.0.971370662284.issue8566@psf.upfronthosting.co.za>
Message-ID: <g2y1afaf6161004301609xa3fa8d23ie0b8d7b894897311@mail.gmail.com>


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

2010/4/30 Jeffrey Yasskin <report at bugs.python.org>:
>
> Jeffrey Yasskin <jyasskin at gmail.com> added the comment:
>
> Thanks. Committed as r80668. May I update http://python.org/dev/peps/pep-0291/ to reflect that 2to3 should continue working on python-2.5?

I suppose it can't hurt, but I don't know that anyone actually looks
at the either.

----------

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

From report at bugs.python.org  Sat May  1 01:16:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 23:16:26 +0000
Subject: [issue8584] test_multiprocessing skips some tests
In-Reply-To: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>
Message-ID: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>


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

Some tests in test_multiprocessing (py3k) are skipped because they "require _ctypes", but I do have ctypes. Here are the skipped tests:

test_array (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_getobj_getlock_obj (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'
test_rawarray (test.test_multiprocessing.WithProcessesTestArray) ... skipped 'requires _ctypes'

test_copy (test.test_multiprocessing.WithProcessesTestSharedCTypes) ... skipped 'requires _ctypes'
test_sharedctypes (test.test_multiprocessing.WithProcessesTestSharedCTypes) ... skipped 'requires _ctypes'
test_synchronize (test.test_multiprocessing.WithProcessesTestSharedCTypes) ... skipped 'requires _ctypes'

test_getobj_getlock (test.test_multiprocessing.WithProcessesTestValue) ... skipped 'requires _ctypes'
test_rawvalue (test.test_multiprocessing.WithProcessesTestValue) ... skipped 'requires _ctypes'
test_value (test.test_multiprocessing.WithProcessesTestValue) ... skipped 'requires _ctypes'

----------
assignee: jnoller
components: Tests
messages: 104675
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing skips some tests
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  1 01:25:58 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Fri, 30 Apr 2010 23:25:58 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272669958.46.0.751435830057.issue8583@psf.upfronthosting.co.za>


Dmitry Chichkov <dchichkov at gmail.com> added the comment:

And obviously iterparse can be either overridden in the local user code or patched in the library. Here's the iterparse code/test code:

import  cElementTree
from cStringIO import StringIO

class iterparse(object):
    root = None
    def __init__(self, file, events=None, namespace_separator = "}"):
        if not hasattr(file, 'read'):
            file = open(file, 'rb')
        self._file = file
        self._events = events
        self._namespace_separator = namespace_separator
    def __iter__(self):
        events = []
        b = cElementTree.TreeBuilder()
        p = cElementTree.XMLParser(b, namespace_separator= \
                                        self._namespace_separator)
        p._setevents(events, self._events)
        while 1:
          data = self._file.read(16384)
          if not data:
            break
          p.feed(data)
          for event in events:
            yield event
          del events[:]
        root = p.close()
        for event in events:
          yield event
        self.root = root


x = """<root xmlns="http://www.very_long_url.com"><child>text</child></root>"""
context = iterparse(StringIO(x), events=("start", "end", "start-ns"))
for event, elem in context: print event, elem

context = iterparse(StringIO(x), events=("start", "end", "start-ns"), namespace_separator = None)
for event, elem in context: print event, elem


It produces:
start-ns ('', 'http://www.very_long_url.com')
start <Element '{http://www.very_long_url.com}root' at 0xb7ccf650>
start <Element '{http://www.very_long_url.com}child' at 0xb7ccf5a8>
end <Element '{http://www.very_long_url.com}child' at 0xb7ccf5a8>
end <Element '{http://www.very_long_url.com}root' at 0xb7ccf650>
start <Element 'root' at 0xb7ccf620>
start <Element 'child' at 0xb7ccf458>
end <Element 'child' at 0xb7ccf458>
end <Element 'root' at 0xb7ccf620>

Note the absence of URIs and ignored start-ns events in the 'space_separator = None' version.

----------

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

From report at bugs.python.org  Sat May  1 01:26:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Apr 2010 23:26:24 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272669984.37.0.0612659485085.issue8576@psf.upfronthosting.co.za>


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

> OK. I've attached a patch which removes the use of get_unused_port for 
> test_smtplib and test_multiprocessing.

Great, thank you. It was committed in r80669 (trunk), r80670 (2.6), r80671 (py3k), r80672 (3.1).
Note that there are still a couple of tests using find_unused_port, depending on the branch: test_httplib, test_logging, test_socket.

----------

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

From report at bugs.python.org  Sat May  1 01:31:46 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 30 Apr 2010 23:31:46 +0000
Subject: [issue8566] 2to3 should run under python 2.5
In-Reply-To: <1272498754.37.0.0259400258036.issue8566@psf.upfronthosting.co.za>
Message-ID: <1272670306.91.0.832182372783.issue8566@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Done.

----------
keywords:  -needs review
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat May  1 02:24:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 00:24:00 +0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1272673440.6.0.220102003674.issue1540617@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as out of date.

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sat May  1 02:34:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 00:34:53 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272674093.75.0.658018558467.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As far as I can tell there's no bug in 3.x:  the 3.x range happily accepts an instance of a  class that defines __index__.

----------
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  1 02:53:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 00:53:40 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272675220.66.0.964758512902.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Currently, in trunk, I get:

>>> range(0.0, 11.0, 1.1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: range() integer start argument expected, got float.

But with Alexander's patch on trunk, I get:

>>> range(0.0, 11.0, 1.1)
[0L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L]

I'm not sure whether this is intentional or not, but IIRC it was a very deliberate choice not to allow float arguments to range (especially when, as here, the arguments are simply being truncated).  I don't think this is an acceptable change for 2.7 (still less for 2.6).

Any patch for this issue should not change the behaviour for small arguments.

IMO, the *right* solution is to convert arguments via __index__ when possible (as 3.x appears to already do).  However, this would be a new feature.  I suggest closing this as a 'won't fix'.

----------
stage:  -> unit test needed

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

From report at bugs.python.org  Sat May  1 03:05:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 01:05:59 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272675959.19.0.857653111154.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> IIRC, it was a very deliberate choice not to allow float arguments to range

Ignore this bit.  IDRC.  It was a deliberate choice not to let something range(0.0, 1.0, 0.1) work to give [0.0, 0.1, ...], since the usual floating-point difficulties give uncertainty about the endpoint.

That float arguments were allowed (and silently truncated to integers) is merely unfortunate.  :)  And it's no longer permitted in 2.7;  I wouldn't want to go back to permitting float arguments here.

I'll set this to pending;  it should be closed unless someone comes up with a simple fix in the near future.

----------
resolution:  -> wont fix
status: open -> pending

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

From report at bugs.python.org  Sat May  1 03:13:17 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Sat, 01 May 2010 01:13:17 +0000
Subject: [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272676397.83.0.71995634104.issue8556@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

Attaching a patch against the trunk, unified format, changed to 'number' as per suggestion.

----------
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file17155/stdtypes.rst.trunk.patch

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

From report at bugs.python.org  Sat May  1 03:15:37 2010
From: report at bugs.python.org (Alex)
Date: Sat, 01 May 2010 01:15:37 +0000
Subject: [issue8585] zipimporter.find_module is untested
In-Reply-To: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>
Message-ID: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

There are no tests for zipimporter.find_module in the success case, only tests that it handles invalid inputs ok.  I'll work up some tests for this tomorrow probably.

----------
components: Extension Modules
messages: 104684
nosy: alex
priority: normal
severity: normal
status: open
title: zipimporter.find_module is untested

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

From report at bugs.python.org  Sat May  1 03:16:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 01:16:46 +0000
Subject: [issue8585] zipimporter.find_module is untested
In-Reply-To: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>
Message-ID: <1272676606.48.0.649117076137.issue8585@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests -Extension Modules
nosy: +brett.cannon, ncoghlan
stage:  -> needs patch
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/issue8585>
_______________________________________

From report at bugs.python.org  Sat May  1 03:25:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 01:25:34 +0000
Subject: [issue665761] reduce() masks exception
Message-ID: <1272677134.98.0.768860686956.issue665761@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am attaching a patch with unit tests that implements the "middle-ground approach" making map and reduce behave the way zip is now.

I my view this slightly preferable to the "all the way" approach of letting all exceptions to propagate up.  My reasoning is that out of the three functions, zip, reduce and map, zip is probably the most common and changing its behavior is more likely to affect somebody than a change to the other two.

----------
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file17156/issue665761.diff

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

From report at bugs.python.org  Sat May  1 03:33:21 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:33:21 +0000
Subject: [issue4908] Implement PEP 376
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1272677601.96.0.0495431795683.issue4908@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:36:39 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:36:39 +0000
Subject: [issue8312] Add post/pre hooks for distutils commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1272677799.77.0.272577840219.issue8312@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:38:05 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:38:05 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1272677885.5.0.867005711372.issue8324@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:39:26 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:39:26 +0000
Subject: [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1272677966.51.0.464654948774.issue8255@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:40:10 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:40:10 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1272678010.23.0.0526521182323.issue8254@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:41:41 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:41:41 +0000
Subject: [issue8252] add a metadata section in setup.cfg
In-Reply-To: <1269786516.47.0.241877166963.issue8252@psf.upfronthosting.co.za>
Message-ID: <1272678101.74.0.895408501455.issue8252@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:42:53 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:42:53 +0000
Subject: [issue8250] Implement pkgutil APIs as described in PEP 376
In-Reply-To: <1272678173.42.0.252891919751.issue8250@psf.upfronthosting.co.za>
Message-ID: <1272678173.42.0.252891919751.issue8250@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

is this a dupe of 4908?

----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 03:51:35 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 01:51:35 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1272678695.09.0.579703750419.issue5302@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 04:01:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 02:01:21 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272679281.23.0.49327920101.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I agree that this issue should be closed with no further action, but for historical accuracy the resolution should be "out of date" rather than "won't fix".  The original bug was about range() behavior when it get arguments that are not ints, but "coerce-able into ints via __int__".  Since range() no longer accepts such arguments, the issue is moot and there is nothing to fix or not fix here.

As a pie in the sky idea, I always wanted a range function that would work on any arguments that support addition and ordering.  For example range(date(2010,1,1), date(2010, 2, 1), timedelta(7)) to return all Fridays in January, 2010.  However, since advent of generator functions, this became simply

def range(start, stop, step):
   while start < stop:
      yield start
      start += step

and thus unnecessary for stdlib.

----------
nosy: +Alexander.Belopolsky -belopolsky
status: pending -> open

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

From report at bugs.python.org  Sat May  1 04:05:47 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 02:05:47 +0000
Subject: [issue8253] add a resource+files section in setup.cfg
In-Reply-To: <1269786855.85.0.280361789745.issue8253@psf.upfronthosting.co.za>
Message-ID: <1272679547.3.0.870768655202.issue8253@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 04:08:06 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 02:08:06 +0000
Subject: [issue8357] Add a --show-installation-paths in the install command
In-Reply-To: <1270826117.06.0.843410920049.issue8357@psf.upfronthosting.co.za>
Message-ID: <1272679686.04.0.416790400736.issue8357@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  1 04:19:54 2010
From: report at bugs.python.org (Paul Jimenez)
Date: Sat, 01 May 2010 02:19:54 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1272680394.19.0.712926750494.issue1462525@psf.upfronthosting.co.za>


Paul Jimenez <pj at place.org> added the comment:

That sounds great - at least something useful will come out of this, even if it's just more tests for urlparse :)

----------

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

From report at bugs.python.org  Sat May  1 04:39:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 02:39:21 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272681561.29.0.273605671753.issue8582@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Sat May  1 04:49:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 02:49:44 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272682184.79.0.794507377131.issue8582@psf.upfronthosting.co.za>


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

I guess the problem with specific to Windows. I don't see any problem with urlretrieve of a image/png url on Linux.
And surprisingly, %T of time.strftime is undocumented:
http://docs.python.org/library/time.html

I wanted to check if that format specifier was platform specific.

----------
components: +Windows

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

From report at bugs.python.org  Sat May  1 05:22:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 03:22:09 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272684129.02.0.727901626053.issue8582@psf.upfronthosting.co.za>


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

The fact that our docs don't mention it is a clue that it is platform dependent :)

Theoretically it shouldn't be, since it is in Posix:

  http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html

but practically speaking it is, since Windows doesn't support it:

  http://msdn.microsoft.com/en-us/library/fe06s4ak.aspx

Apparently not all unix/linux platforms support it either:

  http://stackoverflow.com/questions/2034242/date-and-strftime-not-same-on-windows-and-linux-why

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat May  1 05:23:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 03:23:10 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272684190.03.0.858465242259.issue8582@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> unit test needed
type: crash -> behavior
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  1 06:06:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 04:06:27 +0000
Subject: [issue5109] array.array constructor very slow when passed an array
	object.
In-Reply-To: <1233318806.98.0.166527784762.issue5109@psf.upfronthosting.co.za>
Message-ID: <1272686787.13.0.208130246659.issue5109@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Attached patch makes array(t, a) use memcpy when t == a.typecode.

The code array_new can probably be refactored to eliminate redundant checks, but with a good C compiler this probably have no performance effect.  While refactoring can simplify the code, it will probably complicate the patch.

----------
keywords: +patch
nosy: +Alexander.Belopolsky
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file17157/issue5109.diff

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

From report at bugs.python.org  Sat May  1 06:29:52 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 01 May 2010 04:29:52 +0000
Subject: [issue665761] reduce() masks exception
Message-ID: <1272688192.14.0.305563949632.issue665761@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May  1 06:38:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 04:38:55 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272688735.11.0.796863177903.issue8582@psf.upfronthosting.co.za>


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

Here is the patch and the unittest for this issue.
David: The tests does ensure coverage of urlretrieve method.

- Changes %T to %H:%M:%S in strftime usage in retrieve.
- Coverage of Date header of retrieved file according to format specified.

David, any comments or any further coverage required?

----------
keywords: +patch
Added file: http://bugs.python.org/file17158/issue8582.diff

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

From report at bugs.python.org  Sat May  1 06:58:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 01 May 2010 04:58:29 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272689909.63.0.672401428397.issue1533@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Sat May  1 08:14:53 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 May 2010 06:14:53 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272694493.11.0.973485471963.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I have completed the exception handling code as prototyped in msg101687.  Please review.

----------
assignee:  -> jafo
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17159/logexception2.patch

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

From report at bugs.python.org  Sat May  1 09:43:17 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 01 May 2010 07:43:17 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272699797.54.0.343065956758.issue8581@psf.upfronthosting.co.za>


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

This part of the code has been changed in trunk (to use weak references), and the error does not occur in Python 2.7/3.2.

I'm not sure I fully agree with your assertion that it's not a programmer error to close a handler twice - this could certainly happen as a result of a bug in the application.

So, I'm not sure (now that we're in Python 2.7 beta) that it's worth backporting this to 2.6.6.

Thoughts?

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

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

From report at bugs.python.org  Sat May  1 09:50:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 07:50:12 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272700212.85.0.199948195928.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Alexander: range *does* still accept such arguments (in 2.7);  just not floats:

>>> from decimal import Decimal
>>> range(Decimal(20), Decimal(20))
[]
>>> range(Decimal('1e100'), Decimal('1e100'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: range() integer start argument expected, got Decimal.

----------

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

From report at bugs.python.org  Sat May  1 10:22:53 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 01 May 2010 08:22:53 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272702173.49.0.935335399935.issue8581@psf.upfronthosting.co.za>


Santoso Wijaya <santa.ant at me.com> added the comment:

File-like objects handle multiple close() gracefully, silently making the second and subsequent close() calls to an already closed I/O object do nothing. Why can't the same expectation be applied to logging handlers?

----------
status: pending -> open

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

From report at bugs.python.org  Sat May  1 10:32:51 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 01 May 2010 08:32:51 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1272702771.52.0.76290627033.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've cleaned up the patch and made it clearer that platforms other than OSX aren't affected by rewriting code like this:

f = os.path.join(d, "db.h")
if sys.platform == "darwin" and is_macosx_sdk_path(d):
   f = os.path.join(sysroot, d[1:], "db.h")

The new version of the patch is also more compreshensive, I've added SDK-awareness code for the sqlite and bdb extensions as well, those looked for files without using find_file (because they do more than just look at files).

I can build unix-style and framework builds with this patch, both with and without specifying SDKs. I haven't tested the results on a linux box yet.

I intent to apply this patch on sunday.

Note: the patch intentionally doesn't include an update to Misc/NEWS, I will write that bit when I actually commit. 

I'll also forward port to 3.2 when committing.

----------
keywords: +patch
Added file: http://bugs.python.org/file17160/issue7724-v2.patch

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

From report at bugs.python.org  Sat May  1 10:33:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 08:33:28 +0000
Subject: [issue8582] urllib.urlretrieve fails with ValueError: Invalid format
	string
In-Reply-To: <1272661597.76.0.557782808753.issue8582@psf.upfronthosting.co.za>
Message-ID: <1272702808.22.0.394173492531.issue8582@psf.upfronthosting.co.za>


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

Fixed in trunk: r80675
release26-maint: r80676
py3K: r80677
release31-maint:r80678

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

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

From report at bugs.python.org  Sat May  1 11:52:00 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 01 May 2010 09:52:00 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272702173.49.0.935335399935.issue8581@psf.upfronthosting.co.za>
Message-ID: <123523.34784.qm@web25806.mail.ukl.yahoo.com>


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

----- Original Message ----

> From: Santoso Wijaya <report at bugs.python.org>
> File-like objects handle multiple close() gracefully, silently 
> making the second and subsequent close() calls to an already closed I/O object 
> do nothing. Why can't the same expectation be applied to logging 
> handlers?

I'm not objecting to the change on philosophical grounds, merely commenting that it doesn't happen in 2.7/3.2 and suggesting it's not worth fixing in 2.6/3.1.

----------

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

From report at bugs.python.org  Sat May  1 12:01:48 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:01:48 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1272708108.07.0.244169329085.issue4388@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I still see this failure on Python 3 trunk with Mac OS X 10.6.

----------
nosy: +michael.foord

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

From report at bugs.python.org  Sat May  1 12:27:00 2010
From: report at bugs.python.org (Paul Moore)
Date: Sat, 01 May 2010 10:27:00 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272709620.63.0.815396146873.issue8576@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Here's a patch for test_logging. It needed a minor tweak to logging.config - but I can't see anywhere that this affects the documentation, so I didn't do a doc patch. I hope that's OK.

I'll have a look at test_socket but that looks a bit too deep for me. And test_httplib seems to be testing that if you supply a specific port, the connection socket actually connects on that port, so I can't really see any way of avoiding needing a specific unused port there :-(

----------
Added file: http://bugs.python.org/file17161/test_logging.patch

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

From report at bugs.python.org  Sat May  1 12:38:15 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:38:15 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

I get the following failure running test_imp on py3k, Mac OS X 10.6.3.


======================================================================
ERROR: test_package___file__ (__main__.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 303, in test_package___file__
    support.forget('pep3147')
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/pep3147.pyc'

----------
messages: 104702
nosy: brett.cannon, michael.foord
priority: normal
severity: normal
stage: unit test needed
status: open
title: test_imp.py test failures on Py3K Mac OS X
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 12:44:56 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:44:56 +0000
Subject: [issue8587] test_import.py test failures on Py3K Mac OS X
In-Reply-To: <1272710696.01.0.527513394318.issue8587@psf.upfronthosting.co.za>
Message-ID: <1272710696.01.0.527513394318.issue8587@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

I get the following failures with test_import on Mac OS X 10.6.3:


======================================================================
ERROR: test_import (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 93, in test_import
    test_with_extension(".py")
  File "/compile/python-trunk3/Lib/test/test_import.py", line 86, in test_with_extension
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test___cached__ (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test___cached___legacy_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_import_pyc_path (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_missing_source (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_missing_source_legacy (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_package___cached__ (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_package___cached___from_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

======================================================================
ERROR: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/python-trunk3/Lib/test/test_import.py", line 504, in setUp
    self._clean()
  File "/compile/python-trunk3/Lib/test/test_import.py", line 498, in _clean
    forget(TESTFN)
  File "/compile/python-trunk3/Lib/test/support.py", line 227, in forget
    unlink(source + 'c')
  File "/compile/python-trunk3/Lib/test/support.py", line 186, in unlink
    os.unlink(filename)
OSError: [Errno 20] Not a directory: '/dev/null/lib/python32.zip/@test_9343_tmp.pyc'

----------
messages: 104703
nosy: brett.cannon, michael.foord
priority: normal
severity: normal
status: open
title: test_import.py test failures on Py3K Mac OS X
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 12:46:03 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:46:03 +0000
Subject: [issue8587] test_import.py test failures on Py3K Mac OS X
In-Reply-To: <1272710696.01.0.527513394318.issue8587@psf.upfronthosting.co.za>
Message-ID: <1272710763.57.0.379106932455.issue8587@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This is likely related to issue 8586 - the actual failure is very similar (a bad path in support.py).

----------

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

From report at bugs.python.org  Sat May  1 12:49:47 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:49:47 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272710987.9.0.737143193293.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I see similar failures (failing to unlink weird paths from support.py) in: test_imp.py, test_import.py, test_pydoc.py, test_runpy.py,

----------

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

From report at bugs.python.org  Sat May  1 12:54:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:54:18 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272711258.41.0.0132414629432.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

So I'm assuming issue 8587 (same failure in test_import.py) is a duplicate of this. I'll close 8587.

----------

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

From report at bugs.python.org  Sat May  1 12:54:57 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:54:57 +0000
Subject: [issue8587] test_import.py test failures on Py3K Mac OS X
In-Reply-To: <1272710696.01.0.527513394318.issue8587@psf.upfronthosting.co.za>
Message-ID: <1272711297.57.0.919100839797.issue8587@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Assuming this is actually the same problem as issue 8586.

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

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

From report at bugs.python.org  Sat May  1 12:56:49 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:56:49 +0000
Subject: [issue8588] test_urllib2.py test failures on Py3K Mac OS X
In-Reply-To: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>
Message-ID: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Failures on py3k, Mac OS X 10.6.3.


======================================================================
ERROR: test_proxy_https (__main__.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib2.py", line 1010, in test_proxy_https
    r = o.open(req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 655, in <lambda>
    meth(r, proxy, type))
  File "/compile/python-trunk3/Lib/urllib/request.py", line 663, in proxy_open
    if req.host and proxy_bypass(req.host):
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2214, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2183, in proxy_bypass_macosx_sysconf
    hostIP = ip2num(hostIP)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2161, in ip2num
    if len(parts) != 4:
TypeError: object of type 'map' has no len()

======================================================================
ERROR: test_proxy_https_proxy_authorization (__main__.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib2.py", line 1026, in test_proxy_https_proxy_authorization
    r = o.open(req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 367, in _open
    '_open', req)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 655, in <lambda>
    meth(r, proxy, type))
  File "/compile/python-trunk3/Lib/urllib/request.py", line 663, in proxy_open
    if req.host and proxy_bypass(req.host):
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2214, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2183, in proxy_bypass_macosx_sysconf
    hostIP = ip2num(hostIP)
  File "/compile/python-trunk3/Lib/urllib/request.py", line 2161, in ip2num
    if len(parts) != 4:
TypeError: object of type 'map' has no len()

----------
messages: 104708
nosy: michael.foord
priority: normal
severity: normal
status: open
title: test_urllib2.py test failures on Py3K Mac OS X
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 12:57:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 10:57:36 +0000
Subject: [issue8588] test_urllib2.py test failures on Py3K Mac OS X
In-Reply-To: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>
Message-ID: <1272711456.4.0.501855004439.issue8588@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Sat May  1 13:05:20 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 11:05:20 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

If you run test_warnings.py under an ascii terminal (at least on Mac OS X) then test_warnings.CEnvironmentVariableTests.test_nonascii fails. Perhaps the test should be skipped? 

======================================================================
FAIL: test_nonascii (__main__.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_warnings.py", line 758, in <module>
    test_main()
  File "Lib/test/test_warnings.py", line 753, in test_main
    PyEnvironmentVariableTests
  File "/compile/python-trunk3/Lib/test/support.py", line 1053, in run_unittest
    _run_suite(suite)
  File "/compile/python-trunk3/Lib/test/support.py", line 1027, in _run_suite
    result = runner.run(suite)
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 158, in run
    result.printErrors()
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 109, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 116, in printErrorList
    self.stream.writeln("%s" % err)
  File "/compile/python-trunk3/Lib/unittest/runner.py", line 24, in writeln
    self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xf3' in position 121: ordinal not in range(128)


Looks like the traceback here actually comes from unittest trying to report the failure.

----------
messages: 104709
nosy: michael.foord
priority: normal
severity: normal
status: open
title: test_warnings.CEnvironmentVariableTests.test_nonascii fails under an ascii terminal
versions: Python 3.2

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

From report at bugs.python.org  Sat May  1 13:06:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 11:06:41 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1272712001.03.0.172250255475.issue8589@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> brett.cannon
components: +Tests
nosy: +brett.cannon, haypo

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

From report at bugs.python.org  Sat May  1 13:07:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 11:07:56 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272712076.47.0.5957019245.issue8586@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> barry
components: +Tests
nosy: +barry
stage: unit test needed -> needs patch

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

From report at bugs.python.org  Sat May  1 13:08:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 11:08:50 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272712130.26.0.367890806236.issue8576@psf.upfronthosting.co.za>


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

Vinay, are you ok with the proposed patch?

----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat May  1 13:36:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 11:36:08 +0000
Subject: [issue8590] test_httpservers.CGIHTTPServerTestCase failure on
	3.1-maint Mac OS X
In-Reply-To: <1272713768.56.0.588560261666.issue8590@psf.upfronthosting.co.za>
Message-ID: <1272713768.56.0.588560261666.issue8590@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

A failure in test_httpservers.py on 31-maint (not failing in py3k) on Mac OS X 10.6.3:

test_post (__main__.CGIHTTPServerTestCase) ... Traceback (most recent call last):
  File "/private/var/folders/WD/WDk8J3uFE7OM9tRer5Oy4E+++TI/-Tmp-/tmpv_ZniR/cgi-bin/file2.py", line 2, in <module>
    import cgi
  File "/compile/py-31-maint/Lib/cgi.py", line 34, in <module>
    from operator import attrgetter
ImportError: No module named operator
[28226 refs]
FAIL

======================================================================
FAIL: test_post (__main__.CGIHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_httpservers.py", line 379, in test_post
AssertionError: b'' != b'1, python, 123456\n'


Interesting to see the import error during the test. Running python and executing "import operator" works fine.

----------
messages: 104711
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: test_httpservers.CGIHTTPServerTestCase failure on 3.1-maint Mac OS X
versions: Python 3.1

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

From report at bugs.python.org  Sat May  1 13:37:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 11:37:52 +0000
Subject: [issue8588] test_urllib2.py test failures on Py3K Mac OS X
In-Reply-To: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>
Message-ID: <1272713872.46.0.91804883881.issue8588@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Same failure on 31-maint.

----------
versions: +Python 3.1

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

From report at bugs.python.org  Sat May  1 13:54:45 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 11:54:45 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1272714885.21.0.0425889492487.issue4388@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This passes for me in Mac OS X Terminal (a UTF8 terminal) but fails in iTerm (an ascii terminal) on both 31-maint and py3k.

----------

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

From report at bugs.python.org  Sat May  1 15:46:23 2010
From: report at bugs.python.org (Jason Baker)
Date: Sat, 01 May 2010 13:46:23 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272721583.78.0.673872789068.issue8581@psf.upfronthosting.co.za>


Jason Baker <amnorvend at gmail.com> added the comment:

Vinay, I don't necessarily disagree with you.  However, this appears to be  a pretty trivial change.  If there is a 2.6.6, I think this should go in it.

----------

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

From report at bugs.python.org  Sat May  1 15:53:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 13:53:52 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272722032.44.0.254656041687.issue8576@psf.upfronthosting.co.za>


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

Could you special case the test_socket test by checking for the error that Windows sometimes throws and retrying (in a loop for say a second)?  Not ideal, but probably better than adding a sleep or throwing away the test :)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat May  1 15:56:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 13:56:28 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272722188.07.0.65939471914.issue8586@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: barry -> 
nosy: +ezio.melotti, flox

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

From report at bugs.python.org  Sat May  1 16:04:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 14:04:03 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1272722643.18.0.387530485407.issue8589@psf.upfronthosting.co.za>


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

Victor has proposed a patch for the traceback problem for regrtest, I think.  I haven't looked at it, but I wonder if there is something that can instead be done to make unittest work in cases like this when run in an ascii terminal.  See issue 8522.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat May  1 16:10:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 14:10:42 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272723042.85.0.813114141603.issue8586@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> barry

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

From report at bugs.python.org  Sat May  1 16:12:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 14:12:17 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272723137.48.0.495704841749.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a quick fix for Decimal._fix, that just makes sure that it raises exceptions in the appropriate order.

I'll also try to apply the check_precedence methodology included in this patch to every single testcase.  I don't think it's reasonable to add this testing to the test-suite, though:  test_decimal is slow enough as it is.

----------
keywords: +patch
Added file: http://bugs.python.org/file17162/issue8567.patch

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

From report at bugs.python.org  Sat May  1 16:21:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 14:21:20 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272723680.63.0.961553119306.issue8567@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Added file: http://bugs.python.org/file17163/issue8567.patch

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

From report at bugs.python.org  Sat May  1 16:21:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 14:21:32 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272723692.97.0.771748730496.issue8567@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file17162/issue8567.patch

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

From report at bugs.python.org  Sat May  1 16:22:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 01 May 2010 14:22:24 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1272723744.78.0.671486224724.issue8589@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

What does issue 8522 have to do with it - did you mean a different issue? In unittest it could catch the UnicodeEncodeError and write the ascii repr instead.

----------

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

From report at bugs.python.org  Sat May  1 16:48:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 14:48:12 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272700212.85.0.199948195928.issue1533@psf.upfronthosting.co.za>
Message-ID: <k2hd38f5331005010748k9173e80jf99db071add5e688@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sat, May 1, 2010 at 3:50 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Alexander: range *does* still accept such arguments (in 2.7); ?just not floats:
>
>>>> from decimal import Decimal
>>>> range(Decimal(20), Decimal(20))
> []

Decimal must be a special case.  With the code attached by OP and
trunk:80673, I get

$ ./python.exe bad_range.py
...
Traceback (most recent call last):
  File "bad_range.py", line 12, in <module>
    print range(MyInt(2**64), MyInt(2**64+10))
TypeError: range() integer start argument expected, got instance.

Same with new style MyInt:

$ ./python.exe bad_range1.py
...
Traceback (most recent call last):
  File "bad_range1.py", line 12, in <module>
    print range(MyInt(2**64), MyInt(2**64+10))
TypeError: range() integer start argument expected, got MyInt.

----------

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

From report at bugs.python.org  Sat May  1 16:59:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 14:59:39 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272725979.06.0.46983638581.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Decimal is behaving in exactly the same way as MyInt, isn't it? What do you get for range(MyInt(20), MyInt(20))?

----------

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

From report at bugs.python.org  Sat May  1 17:06:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 15:06:08 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272726368.37.0.831411413945.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Better patch, that checks exception precedence for every test case when EXTENDEDERRORTEST is defined.  With this patch, I get 11 test failures in test_decimal (down from 50 test failures before the Decimal._fix fix).

Now we just have to track down the remaining wrongly ordered exceptions...

----------
Added file: http://bugs.python.org/file17164/issue8567_2.patch

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

From report at bugs.python.org  Sat May  1 17:12:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 15:12:18 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272726738.34.0.436532347795.issue8514@psf.upfronthosting.co.za>


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

In posixmodule.c, the following snippet doesn't make sense anymore:

 		if (k == NULL) {
 			PyErr_Clear();
 			continue;
 		}

If memory allocation of the bytes object fails, we should error out.
(same for "if (v == NULL)" a bit later)

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

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

From report at bugs.python.org  Sat May  1 17:15:48 2010
From: report at bugs.python.org (Paul Moore)
Date: Sat, 01 May 2010 15:15:48 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272726948.53.0.118228765601.issue8576@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Might work - but the only ones that were actually failing for me were test_multiprocessing and test_smtplib. So I'm not quite sure where/when the error would be raised on the remaining 2 (socket & httplib). But I'll keep it in mind.

To be honest, the remaining tests haven't actually failed in my experience, I'm now really only seeing if I can remove all uses of find_unused_port on the basis of Jean-Paul's comment that it's "the wrong approach".

----------

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

From report at bugs.python.org  Sat May  1 17:22:05 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 01 May 2010 15:22:05 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1272727325.36.0.978018433689.issue8407@psf.upfronthosting.co.za>


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

One open question regarding interaction with threading.  sigprocmask's behavior in a multithreaded program is unspecified.  pthread_sigmask should be used instead.  I could either expose both of these and let the caller choose, or I could make signal.sigprocmask use pthread_sigmask if it's available, and fall back to sigprocmask.  I don't see any disadvantages of doing the latter, and the former seems like it would create an attractive nuisance.  However, I don't have much experience with sigprocmask; I'm only interested in it because of its use in combination with signalfd.

----------

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

From report at bugs.python.org  Sat May  1 17:22:11 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 15:22:11 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

On first glance, `distutils2.mkpkg` does not reflect the latest and greatest in Python coding standards.  I'd like to take a stab at PEP-(7|8)'ing the whole thing, although I know there are other issues open to add features to the module, so I don't want to cause unnecessary merge pains.  Thoughts?

----------
assignee: tarek
components: Distutils2
messages: 104726
nosy: meatballhat, tarek
priority: normal
severity: normal
status: open
title: update mkpkg to latest coding standards
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/issue8591>
_______________________________________

From report at bugs.python.org  Sat May  1 17:22:24 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 01 May 2010 15:22:24 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1272727344.63.0.578763001751.issue8407@psf.upfronthosting.co.za>


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


----------
nosy: +gps

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

From report at bugs.python.org  Sat May  1 17:34:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 01 May 2010 15:34:28 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1272728068.01.0.141826268134.issue8591@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Pepeightification is ok for things like whitespace that do not break compatibility (don?t waste time doing it manually though, we have automated tools that can be used to reindent the whole of Distutils2). However, renaming classes and functions has to be done with caution, if there?s code out there that depends on the module. Moreover, PEP?8 does not tell everything, e.g. other PEPs describe good practices for doctrings, and a lot of  idioms are not covered in PEP?8. Distutils2 also has the constraint of having to stay compatible with Python?2.4. Personally, I also find that the name of the script is misleading.

That said, I don?t know the status of mkpkg. If we aim at removing the setup.py script, a utility that helps writing setup.py scripts is doomed to be removed. Or it may be repurposed to write a setup.cfg file.

----------
nosy: +merwok
type: behavior -> 
versions:  -3rd party

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

From report at bugs.python.org  Sat May  1 17:35:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 15:35:56 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272725979.06.0.46983638581.issue1533@psf.upfronthosting.co.za>
Message-ID: <t2qd38f5331005010835ha12e03faj7ab77293edd5f7f7@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sat, May 1, 2010 at 10:59 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Decimal is behaving in exactly the same way as MyInt, isn't it?
> What do you get for range(MyInt(20), MyInt(20))?
>

Hmm, maybe there is a 2.7 bug here after all:

[20, 21, 22]
>>> range(MyInt(2**64), MyInt(2**64+3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: range() integer start argument expected, got instance.

Same with Decimal:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: range() integer start argument expected, got Decimal.

----------

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

From report at bugs.python.org  Sat May  1 17:36:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 15:36:03 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1272728163.5.0.212976439647.issue8407@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith -gps

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

From report at bugs.python.org  Sat May  1 17:44:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 15:44:10 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272728650.66.0.329146207677.issue8572@psf.upfronthosting.co.za>


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

It seems that 3.x behavior is correct. I am quoting a relevant section from rfc 2616.

"""
It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each
separated by a comma.
"""

- Should we change the 2.x behavior then? (This can break apps, which might be depending upon the existing behavior of 2.x code)

Also, this bug is on default value, it fair to assume that the default might given as None, or a string and rarely as int. I don't see anyone would have passed it (correctly for current code) as list.

Why don't we handle it at email.message.Message's get_all method?
get_all is supposed to return a list or None.

Attaching a patch (which is almost David's first suggestion).

----------
keywords: +patch
Added file: http://bugs.python.org/file17165/issue8572.diff

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

From report at bugs.python.org  Sat May  1 17:46:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 15:46:40 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272728800.54.0.38520385501.issue8572@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file17165/issue8572.diff

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

From report at bugs.python.org  Sat May  1 17:47:31 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 01 May 2010 15:47:31 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1272728851.25.0.145155826556.issue8572@psf.upfronthosting.co.za>


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

previous patch had a typo and a mistake. uploading the correct one.

----------
Added file: http://bugs.python.org/file17166/issue8572.diff

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

From report at bugs.python.org  Sat May  1 18:42:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 16:42:36 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272732156.93.0.257327892074.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Final patch (?!) fixes all the test failures due to exception precedence issues.

----------
Added file: http://bugs.python.org/file17167/issue8567_3.patch

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

From report at bugs.python.org  Sat May  1 19:28:03 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 01 May 2010 17:28:03 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1272734883.95.0.862774762497.issue8591@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

I probably shouldn't have dropped the PEP8 bomb so much as stated that I feel the module could use some updating.  It's my (very much potentially wrong) understanding that `distutils2.mkpkg` isn't considered library code so much as the guts of a script.  

The reason for my concern about `distutils2.mkpkg` goes something like this:

    - it is a new addition to the distutils toolkit
    - if any kind of walkthrough is to be written for using
      distutils, there's a good chance the `mkpkg` script will
      be mentioned
    - curious folks like myself may look at the source code for
      the script
    - said curious folks may either be new to Python or new to
      programming in general
    - I don't want newcomers getting the wrong idea about Python
      coding standards


I should also mention that I have the same concern(s) about everything in the `Demo` tree of CPython :)

Even if `setup.py` files aren't the eventual goal, if they're around for even another 2 years I think the effort is justified. </2cents>

----------

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

From report at bugs.python.org  Sat May  1 19:56:51 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Sat, 01 May 2010 17:56:51 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272736611.24.0.958408292202.issue8583@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Namespaces are a fundamental part of the XML information model (both xpath and infoset) and all modern XML document formats, so I'm not sure what problem you're trying to solve by pretending that they don't exist.

It's a bit like modifying "import foo" to work like "from foo import *"...

----------
nosy: +effbot

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

From report at bugs.python.org  Sat May  1 20:04:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 18:04:35 +0000
Subject: [issue8592] 'y' does not check for embedded NUL bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>


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

The documentation for the 'y' format (PyArg_ParseTuple and friends) states that:

? The bytes object must not contain embedded NUL bytes; if it does, a TypeError exception is raised. ?

But, reading Python/getargs.c, the strlen() check is actually missing in the code for 'y'.

----------
assignee: loewis
components: Interpreter Core
messages: 104734
nosy: loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: 'y' does not check for embedded NUL bytes
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat May  1 20:05:04 2010
From: report at bugs.python.org (Andreas Lemke)
Date: Sat, 01 May 2010 18:05:04 +0000
Subject: [issue4485] fast swap of "default" Windows python versions
In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za>
Message-ID: <1272737104.83.0.385722900752.issue4485@psf.upfronthosting.co.za>


Andreas Lemke <muesliflyer at nexgo.de> added the comment:

Python 2.5, 2.6, 3.0, etc. are not fully compatible programming languages. And we cannot expect that there will ever be the one and only ultimate version of Python (hopefully). Many of us need to have more than one of them installed simultaneously. Upon opening a Python file, the right version needs to be started. For those of us who use IDLE, we wish the right version to be started with ?Edit with IDLE?. 

Therefore, we need a clean ? pythonic ? solution to this problem.

I am probably not qualified to determine the best such solution. My main concern is that the community takes the issue seriously.

Nevertheless, it seems to me that different file name extensions (.py25, .py26, .py30) would be a good candidate to solve the issue. On Windows, I set up the appropriate file type associations. It worked quite well, except that IDLE doesn't seem to recognize files with extensions other than .py.

----------
nosy: +Andreas24
versions: +Python 2.5

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

From report at bugs.python.org  Sat May  1 20:25:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 18:25:03 +0000
Subject: [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>


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

This patch fixes, reorders and improves c-api/arg.rst.

I would even suggest to go further and single out a couple of "most useful" formats ('s', 'y*', 'i', 'l'...) so that people don't get lost in all the possibilities.

----------
assignee: docs at python
components: Documentation
files: argdoc.patch
keywords: patch
messages: 104736
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Improve c-api/arg.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17168/argdoc.patch

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

From report at bugs.python.org  Sat May  1 21:02:41 2010
From: report at bugs.python.org (Robert Bradshaw)
Date: Sat, 01 May 2010 19:02:41 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272740561.55.0.0218582653387.issue1533@psf.upfronthosting.co.za>


Robert Bradshaw <robertwb at math.washington.edu> added the comment:

Thank you Alexander. Yes, there is still an issue for large operands, and the attached patch does fix it. Floats are explicitly checked for and rejected by PyArg_ParseTuple for the "l" format (as called by builtin_range) so to preserve this behavior we can explicitly check in the argument parsing of handle_range_longs as well.

This all goes away in Py3 due to the unification of int and long. (And I agree that using __index__ rather than __int__ fits better there).

----------
Added file: http://bugs.python.org/file17169/bltinmodule2.diff

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

From report at bugs.python.org  Sat May  1 21:04:21 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sat, 01 May 2010 19:04:21 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272740661.27.0.887910976482.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

@r.david.murray: did you try running my test?  I think it shows that we are pretty darned close to fully portable.  I believe we could fix Popen to make it fully portable pretty easily.  In fact, there may be a pure-python fix.  Documenting the differences would also not be hard.  I would discourage you from relying *solely* on a description such as "uses execvpe on POSIX" to describe the semantics.  Aside from being a nonportable description, it doesn't help anyone who isn't familiar with the POSIX system calls.

----------

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

From report at bugs.python.org  Sat May  1 21:10:44 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 01 May 2010 19:10:44 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1272741044.96.0.963734958184.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

a note on testing: it should be possible to integrate the tests into existing test_pdb.py by simply placing subprocess based tests next to doctest-based tests. This way pdb tests will at least be in a single module. (this is an approach taken by a patch in 
http://bugs.python.org/issue7964)

Would it be better?

----------

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

From report at bugs.python.org  Sat May  1 21:17:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 01 May 2010 19:17:01 +0000
Subject: [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1272741421.05.0.900690784047.issue6822@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Attached is a patch which fixes FTP_TLS class as well and changes the test server a little bit.
Shouldn't retrlines() suffer the same issue?

----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola
versions: +Python 3.1, Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file17170/ftplib.patch

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

From report at bugs.python.org  Sat May  1 21:20:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 19:20:54 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272740561.55.0.0218582653387.issue1533@psf.upfronthosting.co.za>
Message-ID: <u2ud38f5331005011220xe7ef2149n56a9fac1ab6e99e0@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Robert,

Your patch segfaults on Lib/test/test_builtin.py, but I agree with the
approach.  I'll see if it is easy to fix.

----------

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

From report at bugs.python.org  Sat May  1 21:24:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 19:24:17 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272741857.59.0.642466872015.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky

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

From report at bugs.python.org  Sat May  1 21:31:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 19:31:41 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272742301.88.0.83408821555.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Hmm, maybe there is a 2.7 bug here after all:

Yes, indeed!  Which is why I was suggesting 'wont fix' rather than 'out of date' :)

The bltinmodule2.diff patch from Robert causes a segfault in test_builtin on my system;  I haven't looked at the patch itself properly, but there's likely some refcounting problem.

The patch also lacks tests.

----------

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

From report at bugs.python.org  Sat May  1 21:33:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 19:33:28 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272742408.7.0.72268604511.issue1533@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Sat May  1 22:03:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 20:03:09 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272744189.72.0.355962487887.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A couple of suggestions regarding the patch:

(1) I'd suggest leaving the first part of handle_range_longs intact, up to and including the "/* ilow and ihigh correct now; do istep */" block.  Then build out the three "if (!PyInt_Check(...)) ..." blocks below to include argument conversion.  I think the patch would look cleaner this way.

(2) Rather than using PyNumber_Long, I'd prefer an explicit check for, and call to, nb_int.  This is the behaviour that's used for the 'l' getargs format.  PyNumber_Long is considerably more complicated, and involves looking at __trunc__ and __long__;  so if you use PyNumber_Long you'll still end up with inconsistent behaviour between small and large arguments.

----------

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

From report at bugs.python.org  Sat May  1 22:12:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 20:12:23 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272744743.76.0.0821631801495.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch which does not crash or leak (as tested with -R :) and adds a unit test for OP's case.

The problem, however is that it does not work if new style classes are used in the test case.  See disabled (with if 0) test in the patch.

I'll give it some more thought.

----------
Added file: http://bugs.python.org/file17171/bltinmodule3.diff

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

From report at bugs.python.org  Sat May  1 22:15:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 01 May 2010 20:15:35 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272744935.33.0.595503322332.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark,

I did not see your last comment before uploading the last patch.  I think your suggestion to bypass PyNumber_Long will fix the new/old style classes discrepancy.

----------

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

From report at bugs.python.org  Sat May  1 22:19:09 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 May 2010 20:19:09 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272745149.49.0.973776556536.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Jack Diederich commented:

I don't have my tracker login on this computer so I'll post here.
I'd +1 on making the module python with just the core functionality
imported from C (it releases the GIL when doing IO).  Then you
could replace the few hundred lines of C with just the few lines of
python from the prototype.  That said...    The parens in "return
(NULL)" are extra and against PEP 7 (though there are already a
bunch in syslogmodule.c).    You need to NULL check the saved_hook
in newhookobject() before INCREF'ing it.    Should the saved hook
be called after the syslog call?  It might do anything.    The
patch needs unit tests.

----------

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

From report at bugs.python.org  Sat May  1 22:21:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 01 May 2010 20:21:15 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272745275.02.0.869946146863.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Alexander, I think it should be as simple as replacing the if (!PyInt_Check(ilow) && ...) block with something like this:

	if (!PyInt_Check(ilow) && !PyLong_Check(ilow)) {
		PyNumberMethods *nb = Py_TYPE(ilow)->tp_as_number;
		PyObject *temp;
		if (PyFloat_Check(ilow) || nb == NULL || nb->nb_int == NULL) {
			PyErr_Format(PyExc_TypeError,
				     "range() integer start argument expected, got %s.",
				     ilow->ob_type->tp_name);
			goto Fail;
		}
		temp = (*nb->nb_int)(ilow);
		Py_DECREF(ilow);
		ilow = temp;
		if (temp == NULL)
			goto Fail;
	}

and then doing the same for the ihigh and istep blocks.  But I haven't tested this.

Mark

----------

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

From report at bugs.python.org  Sat May  1 22:32:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 20:32:37 +0000
Subject: [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272745957.2.0.494603697666.issue8593@psf.upfronthosting.co.za>


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

Patch uploaded at http://codereview.appspot.com/979047

----------

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

From report at bugs.python.org  Sat May  1 22:33:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 01 May 2010 20:33:02 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>


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

Similarly to issue 3972 the patch in attachment adds a new "source_address" option to FTP class to bind to a specific address when connecting to a remote FTP server.

It must be noted that this gets done for both control and passive data connections (client connecting to server). The latter one solves issue 1661754.

----------
components: Library (Lib)
files: ftplib_source_address.patch
keywords: needs review, patch
messages: 104749
nosy: giampaolo.rodola, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Add a "source_address" option to ftplib
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17172/ftplib_source_address.patch

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

From report at bugs.python.org  Sat May  1 22:39:49 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 01 May 2010 20:39:49 +0000
Subject: [issue1661754] ftplib passive ftp problem on multihomed clients
Message-ID: <1272746389.67.0.795497861992.issue1661754@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Issue 8594 is related with this one.

----------
superseder:  -> Add a "source_address" option to ftplib

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

From report at bugs.python.org  Sat May  1 22:57:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 20:57:00 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272747420.7.0.0425371890054.issue8550@psf.upfronthosting.co.za>


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

Here is a patch exposing SSL contexts as the "SSLContext" class. Also, SSL sockets are refactored to create a standalone SSLContext object, unless you create them using the new SSLContext.wrap_socket(). Please note that SSLContexts do not expose much more information than SSL sockets previously did. New SSLContext functionality (such as options) can be added later.

Docs are missing, but tests are there.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17173/sslcontext.patch

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

From report at bugs.python.org  Sat May  1 23:57:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 21:57:09 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272751029.1.0.525938296328.issue8557@psf.upfronthosting.co.za>


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

I didn't run the script.  I have now, but I'm not clear from its output what each test is actually doing, and don't really have the time to figure it out from the code right now.

I think it is probably more efficient to just ask you what your suggestion is for making things more portable?

As for the docs, the docs link to the os.exec python docs, which explain the PATH semantics.  Linking to the Microsoft documentation would equivalently explain the Windows semantics.  An explicit footnote discussing the differences in PATH behavior in the subprocess context would probably be helpful.

----------

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

From report at bugs.python.org  Sun May  2 00:01:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 22:01:57 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1272751317.0.0.760316973602.issue8594@psf.upfronthosting.co.za>


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

You should not use find_unused_port(), because it causes problems on some Windows buildbot. Also, there's something fishy in your patch, because you never set self.source_address.

----------

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

From report at bugs.python.org  Sun May  2 00:04:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 22:04:13 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272751453.31.0.671967376459.issue8214@psf.upfronthosting.co.za>


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

Rewriting another implementation of traceback formatting in C is bad.
Just import the "traceback" module and call the desired function in that module.

----------
nosy: +pitrou
versions:  -Python 2.7

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

From report at bugs.python.org  Sun May  2 00:05:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 22:05:19 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272751519.69.0.52279787416.issue8214@psf.upfronthosting.co.za>


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

Oh, well, sorry. That's what you are already doing. Forget me :)

----------

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

From report at bugs.python.org  Sun May  2 00:40:26 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 May 2010 22:40:26 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272753626.59.0.186090829944.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Thanks for the review Jack.

I was very tempted to split it into C and Python components, but I decided
against it because it's so close to the 2.7 release.  I think it would be
best to defer that for the Python 3 release, because of potential packaging
issues.  I'm open to discussion on that though.

I've changed all the return(NULL)s in the package.

NULL check on saved_hook is done.

I also had the same thought about the saved_hook/syslog ordering, so I've
changed it.

I've added soe unit tests.  I tried getting fancy and testing the exception
handling, but had to fork to do it and then unittests were still catching
the exception, so I just left it the minimal set of tests I put in there.

Thanks.

----------
Added file: http://bugs.python.org/file17174/logexception3.patch

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

From report at bugs.python.org  Sun May  2 01:40:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 01 May 2010 23:40:50 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272757250.64.0.555753336532.issue8214@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The test file should use test_support.import_module("syslog") instead of the try/except, which would then make the skip decorators unnecessary.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Sun May  2 02:03:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 May 2010 00:03:22 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272758602.46.0.659090884038.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This patch, bltinmodule4.diff, seems to work for all cases.

Mark,

It looks like I came up with almost the same logic as you did.   The only difference that I can see is that your code does not check that nb_int returns an integer.  Also I put repeated logic into a separate function.

The patch includes unit tests that pass reference leak test.

----------
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file17175/bltinmodule4.diff

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

From report at bugs.python.org  Sun May  2 02:06:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 May 2010 00:06:20 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272758780.9.0.0745147036968.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17176/bltinmodule4.diff

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

From report at bugs.python.org  Sun May  2 02:06:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 02 May 2010 00:06:27 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272758787.7.0.304442831963.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17175/bltinmodule4.diff

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

From report at bugs.python.org  Sun May  2 02:41:16 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 02 May 2010 00:41:16 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272760876.93.0.436869576591.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Changed to use import_module.

----------
Added file: http://bugs.python.org/file17177/logexception4.patch

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

From report at bugs.python.org  Sun May  2 02:43:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 May 2010 00:43:35 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1272761015.67.0.626359004764.issue8550@psf.upfronthosting.co.za>


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

New patch with docs.

----------
Added file: http://bugs.python.org/file17178/sslcontext2.patch

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

From report at bugs.python.org  Sun May  2 03:16:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 02 May 2010 01:16:00 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272762960.15.0.824722327402.issue8214@psf.upfronthosting.co.za>


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

You shouln't use fail*. They're deprecated.

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

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

From report at bugs.python.org  Sun May  2 03:40:58 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sun, 02 May 2010 01:40:58 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1272764458.97.0.23361871322.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Switched to using assertTrue/assertFalse.

----------
Added file: http://bugs.python.org/file17179/logexception5.patch

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

From report at bugs.python.org  Sun May  2 04:54:44 2010
From: report at bugs.python.org (Julian)
Date: Sun, 02 May 2010 02:54:44 +0000
Subject: [issue8595] Unexpected default timeout in http-client-related
	libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>


New submission from Julian <python_org at somethinkodd.com>:

Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default.

What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range.

This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable.

>From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client.

I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap.

While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 104763
nosy: docs at python, oddthinking
priority: normal
severity: normal
status: open
title: Unexpected default timeout in http-client-related libraries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun May  2 04:55:04 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Sun, 02 May 2010 02:55:04 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272768904.57.0.833151925478.issue8583@psf.upfronthosting.co.za>


Dmitry Chichkov <dchichkov at gmail.com> added the comment:

This patch does not modify the existing behavior of the library. The namespace_separator parameter is optional. Parameter already exists in the EXPAT library, but it is hard coded in the cElementTree.XMLParser code.

Fredrik, yes, namespaces are a fundamental part of the XML information model. Yet an option of having them ignored is a very valuable one in the performance critical code.

----------

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

From report at bugs.python.org  Sun May  2 05:23:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 02 May 2010 03:23:06 +0000
Subject: [issue8595] Explain the default timeout in http-client-related
	libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1272770586.31.0.262145112882.issue8595@psf.upfronthosting.co.za>


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

I am not sure, there can be a default timeout value for client libraries like httplib and urllib2. 

Socket connection do have timeout and as you may have figured out already, the option in httplib and urllib methods is to set/override the socket._GLOBAL_DEFALT_TIMEOUT which is None by default (Wait indefinitely).

Since client libraries are using a global, setting it at once place (say at httplib) has same timeout applicable for other modules within the same process.

I see docs can highlight it more or perhaps link to sockets timeout information.

----------
nosy: +orsenthil
title: Unexpected default timeout in http-client-related libraries -> Explain the default timeout in http-client-related libraries

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

From report at bugs.python.org  Sun May  2 05:43:28 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 02 May 2010 03:43:28 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272771808.49.0.285116788172.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I've uploaded a new probe.py that contains a win32 Popen wrapper that I think acts just like *nix's Popen w.r.t. PATH and environment (pass --fix to demonstrate).  I suggest using this or an equivalent wrapper for Win32, and documenting the fact that with shell=False, filename extensions need to be supplied explicitly on windows.

----------
Added file: http://bugs.python.org/file17180/probe.py

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

From report at bugs.python.org  Sun May  2 05:45:08 2010
From: report at bugs.python.org (Julian)
Date: Sun, 02 May 2010 03:45:08 +0000
Subject: [issue8595] Explain the default timeout in http-client-related
	libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1272771908.38.0.531194630524.issue8595@psf.upfronthosting.co.za>


Julian <python_org at somethinkodd.com> added the comment:

@orsenthil:

Consider the definition of httplib.HTTPConnection.__init__(), in Python 2.6.

   def __init__(self, host, port=None, strict=None,
                timeout=socket._GLOBAL_DEFAULT_TIMEOUT):


This could be replaced with:

   def __init__(self, host, port=None, strict=None,
                timeout=10):

or, perhaps better, 

   def __init__(self, host, port=None, strict=None,
                timeout=httplib._HTTP_DEFAULT_TIMEOUT):

This timeout value is passed to the call in socket.create_connection, so I believe if it is overriden, it only applies to the relevant sockets and not to all sockets globally.

Note: I am not arguing here that this SHOULD be done - it would break existing applications, especially those that were written before Python 2.6 - merely that it COULD be done.

----------

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

From report at bugs.python.org  Sun May  2 06:04:11 2010
From: report at bugs.python.org (pvo)
Date: Sun, 02 May 2010 04:04:11 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>


New submission from pvo <user+python at localhost.localdomain.org>:

Blowfish crypt uses a 128 bit salt, not only the letters [./a-zA-Z0-9]. Despite the different salts, crypt ignores the salt and produces identical encrypted passwords.
The problem occurs on FreeBSD 7.2 with Python 2.5.5 (r255:77872) and Python 2.6.4 (r264:7570) (both from the ports)

python2.6 crypt_blf.py 
 salt: '$2a$05$)O\x0e9\xb7\xb0\xc9\xd6)v.\xd3\x03\xea!\xc1$'
$2a$05$t59ktwmm7.WpI...../5uuAazXv5nUvrWyN1EzMcL6/EQ0HrNyJwq
 salt: '$2a$05$\x1ak\x0c\xfbF\xf5\xdf\xb4\x99\xa6\x12\x81\x8d\xce\xea\x19$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey
 salt: '$2a$05$\x80:\x14\xbb\xc3R\x95\xb9\xcb\xf0#\x04\xbf"\xf7\xe9$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey
 salt: '$2a$05$i\x01 \x10\x13#\xe3\xdc\x80\x90[3\xd5@(\x96$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey
 salt: '$2a$05$<\xa8CY\xa6\x018\xe7\x0b}\x92\xd3\xa1L1\xfb$'
$2a$05$COgstwmm........../5uuu63L/Vi1a/9FQpklC2BKZ74ai8JM2ey

----------
components: Library (Lib)
files: crypt_blf.py
messages: 104768
nosy: pvo
priority: normal
severity: normal
status: open
title: crypt blowfish 'ignores' salt
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17181/crypt_blf.py

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

From report at bugs.python.org  Sun May  2 06:05:04 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 02 May 2010 04:05:04 +0000
Subject: [issue8595] Explain the default timeout in http-client-related
	libraries
In-Reply-To: <1272771908.38.0.531194630524.issue8595@psf.upfronthosting.co.za>
Message-ID: <20100502040449.GA3810@remy>


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

On Sun, May 02, 2010 at 03:45:09AM +0000, Julian wrote:
> Note: I am not arguing here that this SHOULD be done - it would
> break existing applications, especially those that were written
> before Python 2.6 - merely that it COULD be done.

I get your point, Julian. What I was worried about is, is it the
"correct thing" to do? Which I am not sure and I believe it is not as
httplib and urllib are not client themselves but are libraries to
build clients. httplib and urllib can be considered as convenient
interfaces over underlying sockets.

Breaking of existing apps is the next question, which should
definitely be avoided. And an explanation in the docs certainly seems
to be the way to go.

----------

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

From report at bugs.python.org  Sun May  2 07:45:31 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sun, 02 May 2010 05:45:31 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

I maintain a Python package which comes with assembly optimizations -- http://tahoe-lafs.org/trac/pycryptopp . Someone was porting this package to Win64 today and discovered that distutils couldn't build it because the Microsoft compiler on Win64 doesn't allow in-line assembly and distutils doesn't know how to build out-of-line assembly (see also http://stackoverflow.com/questions/1664812/can-pythons-distutils-compile-s-assembly which says that there isn't a known way to do this).

So the fellow who is porting pycryptopp to Win64 for me, Samuel Neves, found this hack in someone else's setup.py file: http://bitbucket.org/ambroff/greenlet/src/3ad4830aa109/setup.py

We're probably going to adapt that hack to the pycryptopp setup.py file in order to work around this problem.

But then another fellow named Josip Djolonga who is a GSoC student working on Distutils2 suggested that we could patch the compiler class to use assembly files and pass them to cl.exe. Samuel worked up a patch that does that and then he was able to build pycryptopp on Win64. Here is his patch attached as a file.

Note that we will still need to do some work-around in the pycryptopp setup.py file in order to make pycryptopp buildable on Win64 with older versions of Python that do not have this fix. Any suggestions on the best way to do that would be welcome.

Oops, I see that Samuel gave me the patch in traditional diff form instead of unified diff form. I hope you can accept it anyway since he has gone to bed.

----------
assignee: tarek
components: Distutils
files: patch.diff
keywords: patch
messages: 104770
nosy: tarek, zooko
priority: normal
severity: normal
status: open
title: build out-of-line asm on Windows
type: behavior
Added file: http://bugs.python.org/file17182/patch.diff

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

From report at bugs.python.org  Sun May  2 10:37:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 08:37:41 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272789461.94.0.958146893344.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks---the new patch looks good.  Pulling the argument conversion out into a separate function makes the whole thing much cleaner.

I still have a couple of nits:

 - Please add a comment before get_range_argument indicating
   what it's for.  I'd also consider naming the function something
   more descriptive like 'convert_range_argument' rather than
   'get_range_argument', but I've never been good with names...

 - Good catch about checking the return type of nb_int.  The error
   message should refer to "__int__" though, not "nb_int":  "nb_int"
   won't make much sense to most Python users.

 - I notice that get_range_argument steals a reference to arg.  That's
   fine of course, but it's a little bit unusual, so there should be
   a comment pointing that out somewhere.  It *might* be preferable to
   not steal the reference, and just do the usual 'return a new
   reference' thing instead; I know that leads to a little bit
   more boilerplate in handle_range_longs, but I think the code ends
   up clearer, and there won't be surprises for someone who tries to
   reuse the code in get_range_argument for their own conversions.  I
   leave it up to you. :)

 - Please could you also add a test for small arguments for each test
   class?

 - Style nit:  the codebase mostly avoids assignments in 'if' conditions;
   please separate the assignment and the NULL test in lines like
   "if (!(ilow = get_range_argument(ilow, "start")))".  Also,
   "if (ilow == NULL)" is preferable to "if (!ilow)".

Thanks again for doing this.

----------

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

From report at bugs.python.org  Sun May  2 11:06:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 09:06:15 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272791175.18.0.188908807776.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thinking about it a bit more, I really would prefer get_range_argument not to steal a reference.  If I'm reading a bit of C code and encounter something like:

  obj = transform(obj);
  if (obj == NULL) ...

my hindbrain immediately starts fretting that something's wrong, and I have to go and ferret out the definition of 'transform' to be sure.  In contrast, patterns like:

  temp = transform(obj);
  Py_DECREF(obj);
  obj = temp;
  if (obj == NULL) ...

are so common and familiar in the Python codebase that they don't raise the same sort of red flag.

----------

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

From report at bugs.python.org  Sun May  2 11:38:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 09:38:19 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272793099.45.0.00467848043405.issue8533@psf.upfronthosting.co.za>


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

Ok, let's try sys.stderr solution: commited in r80694 (py3k).

If it breaks buildbot outputs, I will revert it and try the second solution.

----------
status: open -> pending

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

From report at bugs.python.org  Sun May  2 11:39:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 09:39:28 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1272793168.2.0.4646621452.issue8589@psf.upfronthosting.co.za>


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

The bug only occurs on Mac OS X because file system encoding is hardcoded to UTF-8 on this OS and the test is skipped if the file system encoding is ASCII.

But the bug is not specific to test_warnings, as mentionned by R. David Murray: #8533 is the real bug. test_warnings is just an example to reproduce it.

I just commited a fix for #8533: it should fix also this issue.

----------
assignee: brett.cannon -> haypo
dependencies: +regrtest: use backslashreplace error handler for stdout

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

From report at bugs.python.org  Sun May  2 11:44:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 09:44:22 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272793462.11.0.0427259650797.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, I've changed the various "nb_int should return int object" error messages in Objects/intobject.c to the more meaningful and accurate message: "__int__ method should return an integer", in r80695.

----------

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

From report at bugs.python.org  Sun May  2 11:50:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 02 May 2010 09:50:15 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1272793815.74.0.658256948903.issue7192@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Firefox doesn't seem to support a full scripting api, which makes opening tabs and windows harder.

I've committed an alternate version of your patch in r80698: This uses osascript to open the url instead of the open command. I've also added a registration for "safari".

The main reason to use osascript instead of just open is that it might be possible to add support for opening new tabs or windows later on by adjusting the script.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Sun May  2 11:56:19 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 02 May 2010 09:56:19 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1272794179.38.0.597812196173.issue7192@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've ported the change to 3.2 as well.

----------

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

From report at bugs.python.org  Sun May  2 11:58:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 09:58:08 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>


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

TestIPv6Environment testcase of test_ftplib uses support.HOST as hostname, and HOST=localhost. Usually, localhost is the name of 127.0.0.1, but not always ::1. On Linux, the usual names for ::1 are ip6-localhost or ip6-loopback. My internet server provider DNS resolver does not always resolv "localhost" as ::1, sometimes it answer 3(NXDOMAIN). Anyway, the name should be resolved by the local DNS resolver, not depend on an external (ISP) DNS server.

The simplest solution is to use "::1" instead of localhost ;-)

----------
components: Tests
messages: 104778
nosy: haypo
priority: normal
severity: normal
status: open
title: test/support: don't use localhost as IPv6 host name
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun May  2 12:06:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 10:06:11 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272794771.96.0.378042087506.issue8596@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I doubt this is a Python issue, since the crypt function does little more than wrap the system crypt function.

What does your man page for crypt say?  Are you sure you're providing a salt that the system crypt accepts?

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sun May  2 12:13:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 10:13:39 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272795219.37.0.733288762354.issue8598@psf.upfronthosting.co.za>


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

Attached patch uses IPV6_HOST='::1'.

----------
keywords: +patch
Added file: http://bugs.python.org/file17183/support_ipv6_host.patch

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

From report at bugs.python.org  Sun May  2 12:15:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 10:15:24 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272795324.34.0.261636072148.issue8596@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Sun May  2 12:17:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 10:17:53 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272795473.7.0.257328962442.issue8598@psf.upfronthosting.co.za>


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

Mac OS X 10.6.3 has "::1  localhost".

My Ubuntu 9.10 has "::1  ip6-localhost ip6-loopback" but I don't rember if I edited this line or not. I don't think so.

----------

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

From report at bugs.python.org  Sun May  2 12:18:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 10:18:16 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272795496.9.0.0810616689661.issue8598@psf.upfronthosting.co.za>


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

Debian Sid has "::1 ip6-localhost ip6-loopback localhost".

----------

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

From report at bugs.python.org  Sun May  2 12:33:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 10:33:55 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272796435.51.0.142117179355.issue8567@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Sun May  2 13:08:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 May 2010 11:08:26 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272798506.18.0.753054866783.issue8533@psf.upfronthosting.co.za>


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

Since it may reorder output, I think it's better revert the patch and try the other solution. However, I don't think you need to replace sys.stdout at all: just output the traceback more carefully.

----------
status: pending -> open

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

From report at bugs.python.org  Sun May  2 13:16:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 11:16:44 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1272799004.95.0.183853334752.issue8455@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm also seeing this on OS X 10.6.  It seems to have started with r80243.

----------
nosy: +mark.dickinson, ronaldoussoren

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

From report at bugs.python.org  Sun May  2 13:20:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 11:20:48 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1272799248.74.0.955344542937.issue8455@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To clarify, that last message was about trunk, where this test is failing for me since r80243.  Adding 2.7 to the versions.

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

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

From report at bugs.python.org  Sun May  2 14:07:26 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Sun, 02 May 2010 12:07:26 +0000
Subject: [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1272802046.44.0.201939425273.issue8538@psf.upfronthosting.co.za>


Changes by Yaniv Aknin <yaniv.aknin at gmail.com>:


----------
nosy: +Yaniv.Aknin

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

From report at bugs.python.org  Sun May  2 15:09:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 May 2010 13:09:53 +0000
Subject: [issue7192] webbrowser.get("firefox") does not work on Mac with
	installed Firefox
In-Reply-To: <1256306857.19.0.981560840081.issue7192@psf.upfronthosting.co.za>
Message-ID: <1272805793.41.0.559564119906.issue7192@psf.upfronthosting.co.za>


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

issue 8238 notes the problem with autoraise and new on windows.  I believe when I looked at that issue that I confirmed that the syntax webbrowser uses on Linux to support those options works on windows with the current firefox, even though I couldn't find them documented anywhere.  If I'm remembering correctly, then I would expect them to work on Mac, as well.

Webbrowser needs to be refactored so that browser specific support is not not required to be also platform specific.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun May  2 16:02:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 02 May 2010 14:02:04 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1272808924.18.0.930837347481.issue8597@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Sun May  2 16:06:37 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 02 May 2010 14:06:37 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1272809197.28.0.194677973953.issue3445@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

Patch updated: bound and unbound methods, user-defined callable, partial object included in test.

By the way,

>>> [id(abs.__doc__) for i in range(5)]
[140714383081744, 140714383081744, 140714383081744, 140714383081744, 140714383081744]
>>> [id(s) for s in [abs.__doc__ for i in range(5)]]
[140714383084040, 140714383082976, 140714383083144, 140714383075904, 140714383081744]

How it can be explained? Built-in functions (and methods) _sometimes_ return a new instance of its '__doc__' (and '__name__'), and sometimes does not.
(I found this trying to include built-in method into the test.)

----------
nosy: +july
Added file: http://bugs.python.org/file17184/update_wrapper-ignore-missing-attributes.patch

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

From report at bugs.python.org  Sun May  2 17:03:46 2010
From: report at bugs.python.org (Oren Held)
Date: Sun, 02 May 2010 15:03:46 +0000
Subject: [issue8599] _execvpe should behaves inconsistently when PATH includes
	a filename
In-Reply-To: <1272812626.29.0.414465850944.issue8599@psf.upfronthosting.co.za>
Message-ID: <1272812626.29.0.414465850944.issue8599@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

A. Description
When running os._execvpe with a relative pathname that does not exist, I'd expect to get ENOENT error. But there is an edge case in which Python throws ENOTDIR error - when the LAST element in PATH is a regular file (e.g. /bin/ls). This case is caused by a sysadmin mistake, but it may happen, as in the system on which I've encountered this bug.

B. Explanation + How to reproduce:
Consider the following case:
PATH="/bin:/bin/ls" # Last part is a filename instead of a directory
>>> import os; os.execvp("blabla", [""])
Throws: OSError: [Errno 20] Not a directory

Now, consider a similar but differently-ordered PATH:
PATH="/bin/ls:/bin" # *First* part is a filename instead of a directory
>>> import os; os.execvp("blabla", [""])
Throws: OSError: [Errno 2] No such file or directory


C. Why this behavior is not good:
First, IMO there is a certain problem here - differently ordered PATH shouldn't throw different exception. In both cases the executable was not found in PATH, both cases are the same for this matter.

Second, the unix shell (e.g. bash) faces the same issue, and behaves differently. It'll return "command not found" to stdout for both ENOENT and ENOTDIR cases, regardless of the element order in PATH.


D. My recommendation
I'd recommend throwing ENOENT even when ENODIR is thrown for some paths. I am not sure what's the least-evil way to do it, I've been thinking of the following patch, but it's not working because it depends on strerror. It also looks kinda ugly:

--- os.py.old	2010-05-02 17:41:21.481909804 +0300
+++ os.py	2010-05-02 18:03:11.261872651 +0300
@@ -386,7 +386,7 @@
                 saved_tb = tb
     if saved_exc:
         raise error, saved_exc, saved_tb
-    raise error, e, tb
+    raise error, error(errno.ENOENT, os.strerror(errno.ENOENT)), tb # DOESNT WORK, no access to os.strerror from here
 
 # Change environ to automatically call putenv() if it exists
 try:

----------
components: Library (Lib)
messages: 104788
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: _execvpe should behaves inconsistently when PATH includes a filename
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun May  2 17:03:59 2010
From: report at bugs.python.org (Oren Held)
Date: Sun, 02 May 2010 15:03:59 +0000
Subject: [issue8599] _execvpe behaves inconsistently when PATH includes a
	filename
In-Reply-To: <1272812626.29.0.414465850944.issue8599@psf.upfronthosting.co.za>
Message-ID: <1272812639.18.0.194268927174.issue8599@psf.upfronthosting.co.za>


Changes by Oren Held <oren at held.org.il>:


----------
title: _execvpe should behaves inconsistently when PATH includes a filename -> _execvpe behaves inconsistently when PATH includes a filename

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

From report at bugs.python.org  Sun May  2 18:10:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 May 2010 16:10:13 +0000
Subject: [issue8599] _execvpe behaves inconsistently when PATH includes a
	filename
In-Reply-To: <1272812626.29.0.414465850944.issue8599@psf.upfronthosting.co.za>
Message-ID: <1272816613.3.0.688926506943.issue8599@psf.upfronthosting.co.za>


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

The python functions are thin wrappers around the system calls, and are reporting the result of calling the corresponding system call.  The fact that the shell chooses to catch both errors and report a single one would be equivalent to, say, the cmd module doing something similar.  It would not be appropriate for the os module to combine the distinct errors into one.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun May  2 18:22:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 02 May 2010 16:22:41 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1272817361.88.0.0614741830906.issue8597@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think this is a duplicate of issue 7546.

----------
nosy: +skrah
type: behavior -> feature request

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

From report at bugs.python.org  Sun May  2 18:36:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 May 2010 16:36:35 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272818195.41.0.204270775764.issue8598@psf.upfronthosting.co.za>


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

All of my Gentoo systems except one have localhost on the ::1 line.  The one that doesn't hasn't been updated in several years.  That one has the same entry for ::1 as your Ubuntu.

The FreeBSD 6.3 box I have access to has localhost on the ::1 line.

It has long been true that there are test failures if the testing system cannot resolve its own hostname, which often requires "fixing" /etc/hosts on linux systems.  You could call this bug a local system configuration error, too, but whether or not that is politic depends on whether or not there are in fact standard distributions that don't have localhost on the ::1 line.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun May  2 19:06:18 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 02 May 2010 17:06:18 +0000
Subject: [issue8597] build out-of-line asm on Windows
In-Reply-To: <1272779131.33.0.179650713526.issue8597@psf.upfronthosting.co.za>
Message-ID: <1272819978.0.0.734344061923.issue8597@psf.upfronthosting.co.za>


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

Distutils is frozen, switching to distutils2

----------
components: +Distutils2 -Distutils

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

From report at bugs.python.org  Sun May  2 19:06:47 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 02 May 2010 17:06:47 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1272820007.21.0.696758518577.issue7546@psf.upfronthosting.co.za>


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

Distutils is frozen, switching to distutils2

----------
components: +Distutils2 -Distutils

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

From report at bugs.python.org  Sun May  2 19:17:41 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 02 May 2010 17:17:41 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1272820661.74.0.377295242953.issue2091@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review
stage: patch review -> commit review

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

From report at bugs.python.org  Sun May  2 19:19:36 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 02 May 2010 17:19:36 +0000
Subject: [issue4180] warnings.simplefilter("always") does not make warnings
	always show up
In-Reply-To: <1224712172.47.0.998538899646.issue4180@psf.upfronthosting.co.za>
Message-ID: <1272820776.24.0.908398151159.issue4180@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> exarkun
keywords: +needs review

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

From report at bugs.python.org  Sun May  2 19:25:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 17:25:48 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272821148.8.0.0599395943887.issue8533@psf.upfronthosting.co.za>


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

As "expected", the patch doesn't work: it randomize the output order :-(

I checked "sparc Ubuntu 3.x": the output order is correct. "test_xxx" lines are written to stdout, "FAIL: ..." + traceback are written to stderr, and the lines are written in the right order.

But it failed on "x86 Tiger 3.x" :
http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/130/steps/test/logs/stdio
http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 3.x/builds/131/steps/test/logs/stdio

When a test is reexecuted in verbose mode, the output is written in red (why not, but it was not the case before my commit), and the stdout and stderr are in a "mixed".

--

antoine> just output the traceback more carefully.

Encode the traceback by hand would be possible, but it's more complex. A possible solution would be to write the output to a StringIO, encode unicode to bytes using the right encoding and backslashreplace error handler, and write the result to stdout. But I don't like buffering the output because the buildbot may hung for different reasons (search in the bug tracker for "test_multiprocessing" or "test_subprocess"...) and the buildbot master may consider the buildbot as dead (no new output since xxx seconds, whereas it's writing to a buffer).

--

I prefer my first simple idea: use backslashreplace error handler for stdout. Let's try: r80703. This commit reverts my previous commit, apply regrtest_stdout_backslashreplace.patch + a fix for multiprocessing mode (regrtest.py -j ...).

----------

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

From report at bugs.python.org  Sun May  2 19:30:24 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 02 May 2010 17:30:24 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272821424.11.0.79873073726.issue8583@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

There is at least one valid use case: code that needs to deal with HTML and XHTML currently has to normalise the tag names in some way, which usually means that it will want to remove the namespaces from XHTML documents to make it look like plain HTML. It would be nice if the library could do this efficiently right in the parser by simply removing all namespace declarations. However, this doesn't really apply to (c)ElementTree where the parser does not support HTML parsing.

I'm -1 on the interface that the proposed patch adds. The keyword argument name and its semantics are badly chosen. A boolean flag will work much better.

The proposed feature will have to be used with great care by users. Code that depends on it is very fragile and will fail when an input document uses unexpected namespaces, e.g. to embed foreign content, or because it is actually written in a different XML language that just happens to have similar local tag names. This kind of code is rather hard to fix, as fixing it means that it will stop accepting documents that previously passed without problems. Rejecting broken input early is a virtue.

All in all, I'm -0.5 on this feature as I'd expect most use cases to be premature optimisations with potentially dangerous side effects more than anything else.

----------
nosy: +scoder

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

From report at bugs.python.org  Sun May  2 19:43:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 May 2010 17:43:07 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272822187.32.0.50620363391.issue8598@psf.upfronthosting.co.za>


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

Oh, I forgot to copy/paste a test_ftplib failure:
======================================================================
ERROR: test_makeport (test.test_ftplib.TestIPv6Environment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/SHARE/SVN/py3k/Lib/test/test_ftplib.py", line 561, in setUp
    self.server = DummyFTPServer((HOST, 0), af=socket.AF_INET6)
  File "/home/SHARE/SVN/py3k/Lib/test/test_ftplib.py", line 213, in __init__
    self.bind(address)
  File "/home/SHARE/SVN/py3k/Lib/asyncore.py", line 329, in bind
    return self.socket.bind(addr)
socket.gaierror: [Errno -5] No address associated with hostname

======================================================================
ERROR: test_transfer (test.test_ftplib.TestIPv6Environment)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/SHARE/SVN/py3k/Lib/test/test_ftplib.py", line 561, in setUp
    self.server = DummyFTPServer((HOST, 0), af=socket.AF_INET6)
  File "/home/SHARE/SVN/py3k/Lib/test/test_ftplib.py", line 213, in __init__
    self.bind(address)
  File "/home/SHARE/SVN/py3k/Lib/asyncore.py", line 329, in bind
    return self.socket.bind(addr)
socket.gaierror: [Errno -5] No address associated with hostname

----------

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

From report at bugs.python.org  Sun May  2 21:29:54 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 19:29:54 +0000
Subject: [issue4687] GC stats not accurate because of debug overhead
In-Reply-To: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za>
Message-ID: <1272828594.44.0.109612069685.issue4687@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

The patch looks obviously correct to me.

I can confirm that the patch applies cleanly both to the trunk and to the 'release26-maint' branch, and that the 'test_gc' tests pass in both cases after applying it and rebuilding.

----------
nosy: +tseaver

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

From report at bugs.python.org  Sun May  2 21:32:12 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 19:32:12 +0000
Subject: [issue4687] GC stats not accurate because of debug overhead
In-Reply-To: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za>
Message-ID: <1272828732.03.0.196585959087.issue4687@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
versions: +Python 2.6

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

From report at bugs.python.org  Sun May  2 21:42:16 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 19:42:16 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1272829336.88.0.0323357967544.issue4265@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

This bug exists on Python 2.6, too.

It seems to me that the right solution here is to use both opened files as context managers.  See attached patch (made against the release26-maint branch).

The patch also cleans up the old-style exception signature in the precondition check.

----------
keywords: +patch
nosy: +tseaver
Added file: http://bugs.python.org/file17185/issue4265_shutil_copyfile.patch

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

From report at bugs.python.org  Sun May  2 21:42:28 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 19:42:28 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1272829348.14.0.499007612767.issue4265@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
versions: +Python 2.6

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

From report at bugs.python.org  Sun May  2 21:48:49 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 19:48:49 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1272829729.68.0.190530267032.issue4265@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

The patch doesn't apply cleanly to trunk.  Attached is one which does.

----------
Added file: http://bugs.python.org/file17186/issue4265_shutil_copyfile-trunk.patch

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

From report at bugs.python.org  Sun May  2 22:07:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 May 2010 20:07:48 +0000
Subject: [issue4687] GC stats not accurate because of debug overhead
In-Reply-To: <1229555179.58.0.313721223376.issue4687@psf.upfronthosting.co.za>
Message-ID: <1272830868.5.0.287295602104.issue4687@psf.upfronthosting.co.za>


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

Thank you. Now committed in r80704 (trunk), r80705 (py3k), r80706 (2.6), r80707 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun May  2 22:16:47 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 20:16:47 +0000
Subject: [issue1777134] minidom pretty xml output improvement
Message-ID: <1272831407.77.0.838132918734.issue1777134@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

The patch applies cleanly to the 2.6 branch, and with minimal fuzz to
the trunk.  Exsting tests pass in both cases, as does the new test.

The added testcase seems plainly correct.

The first hunk of the  diff to Lib/xml/dom/minidom.py is a little messy
/ hard to follow:

- It makes the module less PEP8 conformant (line length > 80, operator
  spacing)

- The 'onetextnode' flag is set, but never used.

The second hunk is somewhat problematic:  it changes 'Text.writexml' to
ignore any explicit 'indent' or 'newl' argument passed, which is a
backwards-incompatible behavior change.  Perhaps changing the default
values for those arguments to 'None', and then using the new code path
in that case, would be the better course, while falling back to the old
one if either is passed.

I'm not sure about the justification for the third hunk at all (removing
the newline at the end of the XML prologue).  There *can't* be any
meaningful whitespace outside of the root element, so we shouldn't have
round-trip issues if we leave it.

----------
nosy: +tseaver

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

From report at bugs.python.org  Sun May  2 22:25:10 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 02 May 2010 20:25:10 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1272831910.45.0.581094992957.issue4265@psf.upfronthosting.co.za>


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


----------
assignee:  -> tarek
nosy: +tarek

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

From report at bugs.python.org  Sun May  2 22:34:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 May 2010 20:34:53 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272832493.69.0.464655816402.issue8514@psf.upfronthosting.co.za>


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

I really, really, REALLY think that it is bad to mix issues. This makes patch review impossible.

This specific issue is about introducing an fsdecode and fsencode function; this is what the bug title says, and what the initial patch did.

Whether or not byte-oriented access to environment variables is also needed is a *separate* issue. -1 on dealing with that in this report.

FWIW, I'm +0 on adding these functions. MAL, please stop messing issue subjects. If you are fundamentally opposed to adding such functions, please request that a PEP be written or something. Otherwise, I accept the original patch.

I'm -1 on issue8514.patch; it is out-of-scope of the issue.

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

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

From report at bugs.python.org  Sun May  2 22:37:36 2010
From: report at bugs.python.org (Tres Seaver)
Date: Sun, 02 May 2010 20:37:36 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1272832656.28.0.44890849306.issue3704@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I can confirm that the patch applies cleanly to the release26-maint
branch, and that the updated test fails without the updated
implementation.

However, the entire approach seems wrong to me:  the patched method
has just called 'request_path', which already cracked the URL using
urlparse.urlparse and put it back together again with
urlparse.urlunparse.

A better fix would be either to call urlparse.urlparse directly, or
else to add an argument to 'request_path' which kept it from doing the
unwanted reassembly.

Attaching a patch which implements the latter strategy.  Greg's new
test passes with this patch applied in place of the part of his patch
which touches Lib/cookielib.py.

----------
nosy: +tseaver
Added file: http://bugs.python.org/file17187/issue3704-better_request_path.patch

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

From report at bugs.python.org  Sun May  2 23:25:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 02 May 2010 21:25:47 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1272835547.48.0.61887337791.issue8598@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Sun May  2 23:27:07 2010
From: report at bugs.python.org (pvo)
Date: Sun, 02 May 2010 21:27:07 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272835627.87.0.594540747642.issue8596@psf.upfronthosting.co.za>


pvo <user+python at localhost.localdomain.org> added the comment:

FreeBSD's crypt(3) doesn't explain the 'salt' for Blowfish crypt exactly. OpenBSD's crypt(3) says: "The Blowfish version of crypt has 128 bits of salt in order to make building dictionaries of common passwords space consuming."

I wrote a few lines of C code. Copied the salts from the output above to it and cryt()ed "test". The result differs:
$2a$05$/Ae.aeamG.....O.../52uwMz3Q1WQSyWoWTy6zNndsrkAl2fnTn.

I hope I'll find some useful hints in the near future.

----------
status: pending -> open

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

From report at bugs.python.org  Sun May  2 23:36:17 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 02 May 2010 21:36:17 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1272836177.15.0.519990363525.issue8594@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> You should not use find_unused_port()

I agree find_unused_port() is the wrong approach in general, but in this case I think there's nothing we can do about it.

> you never set self.source_address.

You're right, I should set it in connect() method.
I'm going to attach a new patch including documentation.

----------

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

From report at bugs.python.org  Sun May  2 23:38:25 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 02 May 2010 21:38:25 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272836305.36.0.770057674505.issue8576@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> find_unused_port is the wrong approach altogether.  Uses of it should 
> be replaced by bind_port and then find_unused_port should be removed

I agree find_unused_port() is the wrong approach in general, but there are certain cases where this is needed. 
See, for example, the test for "source_address" parameter of socket.create_connection() function.

----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Sun May  2 23:42:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 May 2010 21:42:15 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272836535.5.0.0237209784633.issue8576@psf.upfronthosting.co.za>


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

> See, for example, the test for "source_address" parameter of
> socket.create_connection() function.

Instead of testing the port, you could test the host. For example
by using two different loopback addresses (127.0.0.1 and 127.0.0.2?). Would it work on every platform?

----------

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

From report at bugs.python.org  Sun May  2 23:47:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 May 2010 21:47:02 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272836822.24.0.701214883365.issue8596@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> FreeBSD's crypt(3) doesn't explain the 'salt' for Blowfish crypt exactly.

Reading:

http://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&sektion=3&manpath=FreeBSD+7.2-RELEASE&format=html

and especially the section entitled "Modular crypt", it looks like your salt should take the form "$2$salt$ignored", where there are at most 8 characters of salt and the 'ignored' bit is ignored.

So your $2a$ looks wrong to me:  shouldn't it be $2$?  And after that, in the examples that you give, the only used portion of the salt is "05", which is the same in all the examples, so I'd expect to get the same output in each case.

I can't see any way that Python could be contributing to this:  if you look at the implementation (in Modules/cryptmodule.c), you'll see that the crypt function (called crypt_crypt in the source) really is a trivial wrapper around the system function;  there's no pre- or post-processing of arguments.

Can you attach the C code that's giving the different results?

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

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

From report at bugs.python.org  Mon May  3 02:57:44 2010
From: report at bugs.python.org (pvo)
Date: Mon, 03 May 2010 00:57:44 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272848264.96.0.702681793315.issue8596@psf.upfronthosting.co.za>


pvo <user+python at localhost.localdomain.org> added the comment:

$2a$12$saltysalt$ignored
 ^  ^  ^         ^
 |  |  |          \_ignored
 |  |  \_the salt
 |  \_number of rounds (04-31)
 \_ crypt id
 
About the crypt id:
I read too much Blowfish crypt related stuff in the recent both days. Can't 
remember exactly the difference between the IDs '2' and '2a'. The 
/etc/master.passwd on my OpenBSD contains encrypted passwords with the '2a' ID.

The C code is attached.

----------
Added file: http://bugs.python.org/file17188/blf_crypt.c

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

From report at bugs.python.org  Mon May  3 04:00:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 02:00:25 +0000
Subject: [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>


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

All test_gdb tests fail here with both trunk and py3k. The failure is always the same so I'm just quoting one of them below:

======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_gdb.py", line 604, in test_basic_command
    cmds_after_breakpoint=['py-bt'])
  File "/home/antoine/py3k/__svn__/Lib/test/test_gdb.py", line 126, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: 
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
- warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.


This is with:

GNU gdb (GDB) 7.1-1mdv2010.1 (Mandriva Linux release 2010.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-mandriva-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

----------
assignee: dmalcolm
components: Tests
messages: 104810
nosy: dmalcolm, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb failures
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May  3 05:43:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:43:49 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272858229.56.0.0131959548391.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue1533.diff, simplifies reference acrobatics at the expense of extra local variables.  For the first time the first compilation did not have reference counting errors!

----------
Added file: http://bugs.python.org/file17189/issue1533.diff

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

From report at bugs.python.org  Mon May  3 05:43:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:43:56 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272858236.2.0.640591095232.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file9543/bltinmodule.diff

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

From report at bugs.python.org  Mon May  3 05:44:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:44:02 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272858242.38.0.0801308184261.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17171/bltinmodule3.diff

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

From report at bugs.python.org  Mon May  3 05:44:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:44:09 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272858249.43.0.420305312726.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17176/bltinmodule4.diff

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

From report at bugs.python.org  Mon May  3 05:46:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:46:54 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272789461.94.0.958146893344.issue1533@psf.upfronthosting.co.za>
Message-ID: <n2wd38f5331005022046g9577edcdmf057b74d54c6458c@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, May 2, 2010 at 4:37 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> ?- Please could you also add a test for small arguments for each test
> ? class?

Working on it ...

----------

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

From report at bugs.python.org  Mon May  3 05:52:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:52:03 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272858723.58.0.88682202414.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>  - Please could you also add a test for small arguments for each test
>   class?

Done.

----------
Added file: http://bugs.python.org/file17190/issue1533.diff

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

From report at bugs.python.org  Mon May  3 05:52:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 03:52:08 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272858728.69.0.698003606198.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17189/issue1533.diff

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

From report at bugs.python.org  Mon May  3 06:17:26 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Mon, 03 May 2010 04:17:26 +0000
Subject: [issue1429] FD leak in SocketServer
In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za>
Message-ID: <1272860246.32.0.344489844073.issue1429@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

I was toying with adding Unix Socket support for one of our internal tools and I thought I ran into a leak in my own code. Searched the bug tracker and found this.

I tried to reproduce, but wasn't able to. Though, if you look at the ThreadingMixIn class, you'll see this:

self.handle_error(request, client_address)
self.close_request(request)

An exception in handle_error, most likely from a subclass, would cause close_request to never fire. Though, the socket.accept'd channel would probably be shut down implicitly when leaving _handle_request_nonblock.

----------
nosy: +mcjeff

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

From report at bugs.python.org  Mon May  3 06:38:37 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Mon, 03 May 2010 04:38:37 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272861517.21.0.358341555704.issue8583@psf.upfronthosting.co.za>


Dmitry Chichkov <dchichkov at gmail.com> added the comment:

I agree that the argument name choice is poor. But it have already been made by whoever coded the EXPAT parser which cElementTree.XMLParser wraps. So there is not much room here.

As to 'proposed feature have to be used with great care by users' - this s already taken care of. If you look - cElementTree.XMLParser class is a rather obscure one. As I understand it is only being used by users requiring high performance xml parsing for large datasets (10GB - 10TB range) in data-mining applications.

----------

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

From report at bugs.python.org  Mon May  3 07:03:49 2010
From: report at bugs.python.org (Dmitry Chichkov)
Date: Mon, 03 May 2010 05:03:49 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1272863029.67.0.689544472861.issue8583@psf.upfronthosting.co.za>


Dmitry Chichkov <dchichkov at gmail.com> added the comment:

Interestingly in precisely these applications often you don't care about namespaces at all. Often all you need is to extract 'text' or 'name' elements irregardless of the namespace.

----------

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

From report at bugs.python.org  Mon May  3 08:06:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 06:06:21 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1272866781.01.0.583069839461.issue3720@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +26backport

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

From report at bugs.python.org  Mon May  3 08:23:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 06:23:55 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1272867835.14.0.632481205697.issue6763@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh

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

From report at bugs.python.org  Mon May  3 08:34:27 2010
From: report at bugs.python.org (Andrei Paraschivescu)
Date: Mon, 03 May 2010 06:34:27 +0000
Subject: [issue8427] toplevel jumps to another location on the screen
In-Reply-To: <1271451007.13.0.573906972341.issue8427@psf.upfronthosting.co.za>
Message-ID: <1272868467.54.0.737508791383.issue8427@psf.upfronthosting.co.za>


Changes by Andrei Paraschivescu <andreip1 at comcast.net>:


----------
type:  -> behavior

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

From report at bugs.python.org  Mon May  3 08:54:29 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 06:54:29 +0000
Subject: [issue8601] bz2.BZ2File should support "with" protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>


New submission from Matt Wartell <matt.wartell+pt at gmail.com>:

As the bz2.BZ2File object claims to be a file-like object it should conform to PEP 343 "The 'with' statement" by implementation of the __enter__ and __exit__ methods.


boring, substantiating detail follows:
$ uname -a
Linux tallguy 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
>>> with bz2.BZ2File('test.bz2') as infile:
...     pass
... 
AttributeError: 'bz2.BZ2File' object has no attribute '__exit__'

>>> getattr(bz2.BZ2File, '__enter__')
AttributeError: type object 'bz2.BZ2File' has no attribute '__enter__'
>>> getattr(bz2.BZ2File, '__exit__')
AttributeError: type object 'bz2.BZ2File' has no attribute '__exit__'


$ dpkg -l python2.6
ii  python2.6    2.6.5-1ubuntu6     An interactive hig...
$ dpkg -L python2.6 | grep bz2.so
/usr/lib/python2.6/lib-dynload/bz2.so

----------
components: Extension Modules
messages: 104817
nosy: Matt.Wartell
priority: normal
severity: normal
status: open
title: bz2.BZ2File should support "with" protocol per PEP 343
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May  3 09:03:54 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 07:03:54 +0000
Subject: [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>


New submission from Matt Wartell <matt.wartell+pt at gmail.com>:

This is related to http://bugs.python.org/issue8601 "bz2.BZ2File should support "with" protocol per PEP 343"

The documentation at http://docs.python.org/library/bz2.html states:

   "This module provides a comprehensive interface for the bz2 compression library. It implements a complete file interface,..." 

although bz2.BZ2File does not support the __enter__ and __exit__ methods so arguably doesn't implement the "complete file interface". If issue8601 is declined then the documentation should probably note this exception.

----------
assignee: docs at python
components: Documentation
messages: 104818
nosy: Matt.Wartell, docs at python
priority: normal
severity: normal
status: open
title: documentation of bz2 module mildly erroneous
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May  3 09:06:52 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 07:06:52 +0000
Subject: [issue8601] bz2.BZ2File should support "with" protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272870412.68.0.424855827197.issue8601@psf.upfronthosting.co.za>


Matt Wartell <matt.wartell+pt at gmail.com> added the comment:

cross referenced with documentation issue http://bugs.python.org/issue8602 "documentation of bz2 module mildly erroneous"

----------

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

From report at bugs.python.org  Mon May  3 09:28:44 2010
From: report at bugs.python.org (=?utf-8?q?Philipp_T=C3=B6lke?=)
Date: Mon, 03 May 2010 07:28:44 +0000
Subject: [issue5565] Strange behavior when I logout() with IMAP4_SSL
In-Reply-To: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>
Message-ID: <1272871724.24.0.987133704432.issue5565@psf.upfronthosting.co.za>


Philipp T?lke <toelke+pb at model.in.tum.de> added the comment:

The TCP-issues from my post are all resolved. I now know how TCP works; the behaviour of python seems to be correct.

About the imap-behaviour:
me at harga ~$ python
Python 2.5.5 (r255:77872, Apr 21 2010, 08:40:04) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import imaplib
>>> c = imaplib.IMAP4_SSL("post.in.tum.de")
>>> c.login("toelke", "XXX")
('OK', ['LOGIN Ok.'])
>>> c.logout()
('BYE', ['Courier-IMAP server shutting down'])
>>> <C-d>
me at harga ~$

At the time of the logout() the server closes his connection and sends a FIN-packet. If python is closed, it sends not a FIN-Packet but a RST-paket.

The "problem" I have with this is, that the Linux-Packetfilter-Firewall does not expect this RST-Packet either and in out configuration logs this as a connection in the wrong state which is generally a security-problem.

Our workaround for the last year has been

iptables -A OUTPUT  -p tcp --tcp-flags ACK,RST ACK,RST -d 131.159.22.43 -j DROP

Thanks for the help!

----------

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

From report at bugs.python.org  Mon May  3 09:30:34 2010
From: report at bugs.python.org (=?utf-8?q?Philipp_T=C3=B6lke?=)
Date: Mon, 03 May 2010 07:30:34 +0000
Subject: [issue5565] Strange behavior when I logout() with IMAP4_SSL
In-Reply-To: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>
Message-ID: <1272871834.19.0.990411763435.issue5565@psf.upfronthosting.co.za>


Philipp T?lke <toelke+pb at model.in.tum.de> added the comment:

The TCP-issues from my post are all resolved. I now know how TCP works; the behaviour of python seems to be correct.

About the imap-behaviour:
me at harga ~$ python
Python 2.5.5 (r255:77872, Apr 21 2010, 08:40:04) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import imaplib
>>> c = imaplib.IMAP4_SSL("post.in.tum.de")
>>> c.login("toelke", "XXX")
('OK', ['LOGIN Ok.'])
>>> c.logout()
('BYE', ['Courier-IMAP server shutting down'])
>>> <C-d>
me at harga ~$

At the time of the logout() the server closes his connection and sends a FIN-packet. If python is closed, it sends not a FIN-Packet but a RST-paket.

The "problem" I have with this is, that the Linux-Packetfilter-Firewall does not expect this RST-Packet either and in out configuration logs this as a connection in the wrong state which is generally a security-problem.

Our workaround for the last year has been

iptables -A OUTPUT  -p tcp --tcp-flags ACK,RST ACK,RST -d 131.159.22.43 -j DROP

Thanks for the help!

----------

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

From report at bugs.python.org  Mon May  3 10:26:42 2010
From: report at bugs.python.org (Trent Nelson)
Date: Mon, 03 May 2010 08:26:42 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272875202.23.0.0210517301813.issue8576@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

I introduced test_support.find_unused_port in r62234, as part of a general refactoring of client/server network-oriented tests.  The only reason I introduced this method at the time was because the SSL tests used to launch openssl in server mode, which required a port to be specified as part of the command line.

Pure Python tests shouldn't use this method, as noted in the docstring, they should use bind_port(), which takes platform socket-oddities into account.

I'm not sure if I agree that find_unused_port() should be removed though; it does serve a purpose in very rare corner cases.  Perhaps it should be renamed to _find_unused_port() to discourage accidental usage.

(I'd recommend reviewing r62234's commit log and change set for more info.)

----------
nosy: +trent

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

From report at bugs.python.org  Mon May  3 10:34:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 08:34:24 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272832493.69.0.464655816402.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BDE8A8B.2030209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I agree with Martin regarding the os.environ changes. Victor, please
open a new ticket for this.

Martin: As you probably know, these issues are managed as micro-
mailing lists. Discussions on these lists often result in new
aspects which then drift off to new issues. That's normal business
and we are all well aware of this. Please stop yelling all about the
place and change your tone ! Thanks.

----------

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

From report at bugs.python.org  Mon May  3 10:37:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 08:37:05 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1272875825.22.0.0509632550756.issue8533@psf.upfronthosting.co.za>


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

> Let's try: r80703

This one looks ok: the output order is kept and I didn't noticed anything special in the buildbot output.

Backported to 3.1 as r80711. Close the issue.

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

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

From report at bugs.python.org  Mon May  3 10:56:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 08:56:26 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>


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

As discussed in issue #8514, I propose a bytes version of os.envionb which would be synchronized with os.environ (which is possible thanks to surrogateescape error handler).

I also propose a os.getenvb()->bytes function.

I don't know yet if it's a good idea of not, but my patch accepts both bytes and str for os.environ(b).get() and os.getenv(b)().

antoine> In posixmodule.c, (...) if memory allocation of the bytes
antoine> object fails, we should error out.

I would require to change also the Windows version and the code specific to OS/2. Ok to do that, but after closing this issue ;-) I don't want to change to much things at the same time.

----------
components: Interpreter Core, Library (Lib), Unicode
files: os_environb.patch
keywords: patch
messages: 104825
nosy: Arfrever, ezio.melotti, gregory.p.smith, haypo, lemburg, loewis, pitrou
priority: normal
severity: normal
status: open
title: Create a bytes version of os.environ and getenvb()
versions: Python 3.2
Added file: http://bugs.python.org/file17191/os_environb.patch

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

From report at bugs.python.org  Mon May  3 11:02:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 09:02:59 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272877379.47.0.536353580696.issue8514@psf.upfronthosting.co.za>


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

loewis> I really, really, REALLY think that it is bad to mix issues.
loewis> This makes patch review impossible.

I tried to, but it looks difficult :-) Anyway, I opened #8603.

> This specific issue is about introducing an fsdecode and fsencode 
> function; this is what the bug title says, and what the initial patch
> did.

I know, but the two topics (fs*code() and os.environb) are very close and related. My os.environb implementation uses fsencode()/fsdecode().

> FWIW, I'm +0 on adding these functions. MAL, please stop messing
> issue subjects. (...)

I think that we cannot decide correctly about fs*code() until we decided for os.environb.

----------

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

From report at bugs.python.org  Mon May  3 11:10:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 09:10:21 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272877821.14.0.518627744268.issue8603@psf.upfronthosting.co.za>


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

The patch creates also fsencode()/fsdecode() functions proposed in #8514: I can rename them to use protected name (eg. "_encodeenv" and "_decodeenv") until we decided for these functions.

----------

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

From report at bugs.python.org  Mon May  3 11:10:57 2010
From: report at bugs.python.org (pvo)
Date: Mon, 03 May 2010 09:10:57 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272877857.42.0.480153548394.issue8596@psf.upfronthosting.co.za>


pvo <user+python at localhost.localdomain.org> added the comment:

OpenBSD's crypt(3) mentions some bcrypt*() functions. One of this functions is "char * bcrypt_gensalt(u_int8_t log_rounds)". It produces salts like: $2a$04$7.zkQ.HPURlplcFTWgDL3u or $2a$04$l2SuIEWPqF4D3uMTABgBYO

Passing this salts to Pyton's crypt.crypt on FreeBSD works perfect.

Sorry for the noise.

----------

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

From report at bugs.python.org  Mon May  3 11:18:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 May 2010 09:18:08 +0000
Subject: [issue8596] crypt blowfish 'ignores' salt
In-Reply-To: <1272773050.91.0.224780223694.issue8596@psf.upfronthosting.co.za>
Message-ID: <1272878288.35.0.273622724741.issue8596@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, thanks for the update!

Looks like the FreeBSD crypt manpage could use some work...

----------

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

From report at bugs.python.org  Mon May  3 12:30:06 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 May 2010 10:30:06 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272882606.78.0.61833486609.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'm seeing a "similar" (but not identical) failure on py3k / Windows 7 in test_marshal. Failure in the same code path in support.py:

======================================================================
ERROR: test_floats (__main__.FloatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../Lib/test/test_marshal.py", line 14, in helper
    f = open(support.TESTFN, "wb")
IOError: [Errno 13] Permission denied: '@test_5324_tmp'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "../Lib/test/test_marshal.py", line 88, in test_floats
    self.helper(f)
  File "../Lib/test/test_marshal.py", line 26, in helper
    support.unlink(support.TESTFN)
  File "C:\compile\py3k\lib\test\support.py", line 186, in unlink
    os.unlink(filename)
WindowsError: [Error 5] Access is denied: '@test_5324_tmp'

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

----------

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

From report at bugs.python.org  Mon May  3 12:33:54 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 May 2010 10:33:54 +0000
Subject: [issue8586] test.support errors (py3k)
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272882834.02.0.178883918313.issue8586@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
title: test_imp.py test failures on Py3K Mac OS X -> test.support errors (py3k)

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

From report at bugs.python.org  Mon May  3 12:45:23 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 03 May 2010 10:45:23 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272882606.78.0.61833486609.issue8586@psf.upfronthosting.co.za>
Message-ID: <4BDEA93C.8020007@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

This is basically issue 7743 which is a combination of:

* Using the same filename for all tests in one process
* Something (TSvn / Virus Checker) having a delete-share handle
* Not renaming the file before removing it in test.support.unlink

MvL suggested a change to the underlying unlink. I'm unconvinced
that this would solve the issue, but I haven't put together the
test cases needed to show this. For this current issue, I believe
that patching test.support.unlink to rename (to a guid-based
name in the same directory, say) before deleting would solve
all this.

It's fairly reproducible; there's a mini-test harness on
that other call which will throw up these errors often
enough to be useful.

----------
nosy: +tim.golden
title: test.support errors (py3k) -> test_imp.py test failures on Py3K Mac OS X

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

From report at bugs.python.org  Mon May  3 14:43:41 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 03 May 2010 12:43:41 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1272890621.44.0.644179526135.issue3445@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

To Evan Klitzke (eklitzke):

>I'm also interested in seeing this fixed. In the current behavior,
>the following code doesn't work:
>
><<< start code
>from functools import wraps
>
>def magic(func):
>	@wraps(func)
>	def even_more_magic(*args):
>		return func(*args)
>	return even_more_magic
>
>class Frob(object):
>	@magic
>	@classmethod
>	def hello(cls):
>		print '%r says hello' % (cls,)
>>>> end code

This code _should not_ work.

[Unbound] classmethod object is not a method or a function, it is even not a callable; it is a descriptor (returning callable). So, it cannot be wrapped or decorated in such way.

If you want something like this to work, you probably should place @classmethod on the upper level (in other words, apply classmethod after all other decorators):

	@classmethod
	@magic
	def hello(cls):
		print '%r says hello' % (cls,)

----------

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

From report at bugs.python.org  Mon May  3 14:43:59 2010
From: report at bugs.python.org (Olemis Lang)
Date: Mon, 03 May 2010 12:43:59 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>


New submission from Olemis Lang <olemis+py at gmail.com>:

Often I have the contents to be written in a file at a given path that
I know as well. I recently tried to find a function in stdlib to do
that and to my surprise this is what I found :

 - Such function exists
 - It's `distutils.file_util.write_file`

IMO the last place where people'd look for such a function is inside
`distutils` package. Besides I reviewed modules listed under `File and
directory access` category in `Library Reference` and found nothing
even similar.

The idea is to provide a a similar function in `shutils` module

----------
assignee: tarek
components: Distutils
messages: 104833
nosy: olemis, tarek
priority: normal
severity: normal
status: open
title: Alias for distutils.file_util.write_file in e.g. shutils
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon May  3 14:54:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 12:54:19 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272891259.79.0.24960708246.issue8604@psf.upfronthosting.co.za>


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

This sounds silly to me. You can write a file in two lines:

with open("foo", "wb") as f:
    f.write(contents)

If you want to do something more useful, you can add a function for atomic writing of a file.

----------
nosy: +pitrou
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Mon May  3 15:01:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 03 May 2010 13:01:28 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272891688.56.0.0226013724632.issue8604@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Does the standard library really need something so trivial? I'd put it in your own program. And I'd make the one in distutils private (and fix it to use a with statement).

----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon May  3 15:37:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 03 May 2010 13:37:03 +0000
Subject: [issue8601] bz2.BZ2File should support "with" protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272893823.84.0.504651647911.issue8601@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> needs patch
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Mon May  3 15:42:25 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 03 May 2010 13:42:25 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272894145.15.0.703696748784.issue8604@psf.upfronthosting.co.za>


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

@Eric: remember that distutils is frozen, so it won't be removed. And historically Distutils code was meant to be 2.4 compatible (thus, no with)

@Antoine: Yes, that would be the idea (provide a robust pattern by using a temporary file, then rename it)

----------
components: +Library (Lib) -Distutils

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

From report at bugs.python.org  Mon May  3 15:53:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 13:53:11 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272894145.15.0.703696748784.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272894932.21551.0.camel@localhost.localdomain>


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

> @Antoine: Yes, that would be the idea (provide a robust pattern by
> using a temporary file, then rename it)

Then perhaps it would be better as a context manager:

with shutil.atomic_write("foo", "wb") as f:
    f.write("mycontents")

----------

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

From report at bugs.python.org  Mon May  3 15:55:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 13:55:14 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272877821.14.0.518627744268.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BDED5BD.50807@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

A view comments on the patch:

+    def __init__(self, data, encodekey, decodekey, encodevalue, decodevalue, putenv, unsetenv):

As general guideline: When adding new parameter, please add them to the
end of the parameter list and preferably with a default argument in order
to not break the API.

Doesn't matter much in this case, since _Environ is only used internally,
but it's still good practice.

--

+data = {}
+for key, value in environ.items():
+    data[_keymap(key)] = fsencode(value)

Please put such init code into a function or make sure that the global
module space is not polluted with temporary variables such as data,
key, value.

--

+    # bytes environ
+    environb = _Environ(data, _keymap, fsencode, fsencode, fsencode, _putenv, _unsetenv)

This looks wrong even though it will work, but that's only a
side-effect of how fsencode is coded and that's not how the
stdlib should be coded (see below).

--

+    def fsencode(value):
+        """
+        unicode to file system
+        """
+        if isinstance(value, bytes):
+            return value
+        else:
+            return value.encode(sys.getfilesystemencoding(), 'surrogateescape')

The function should not accept bytes as input or at least
document this pass-through behavior, leaving the user to decide
whether that's wanted or not.

--

The patch is also missing code which keeps the two dictionaries in
sync. If os.environ changes, os.environb would have to change as
well.

----------

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

From report at bugs.python.org  Mon May  3 16:25:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 14:25:45 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272896745.42.0.0339445191463.issue8603@psf.upfronthosting.co.za>


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

> The patch is also missing code which keeps the two dictionaries in
> sync. If os.environ changes, os.environb would have to change as
> well.

No, it doesn't :-) os.environ and os.environb are synchronized and there is a test for this! ;-)

I will see later for your other comments.

----------

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

From report at bugs.python.org  Mon May  3 16:35:19 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 03 May 2010 14:35:19 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272897319.9.0.939287466056.issue8586@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Surely not bug 7743 "Additional potential string -> float conversion issues."

----------

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

From report at bugs.python.org  Mon May  3 16:45:10 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 03 May 2010 14:45:10 +0000
Subject: [issue8601] bz2.BZ2File should support "with" protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272897910.34.0.971968254882.issue8601@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

BZ2File objects already support the context manager protocol on the trunk, as of Antoine Pitrou's fix for http://bugs.python.org/issue3860

----------
nosy: +tseaver

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

From report at bugs.python.org  Mon May  3 17:08:38 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 03 May 2010 15:08:38 +0000
Subject: [issue839159] iterators broken for weak dicts
Message-ID: <1272899318.44.0.598189611846.issue839159@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I can confirm that the patch applies with minimal fuzz to the
release26-maint branches and the trunk, and that the added tests fail
without the updated implementation in both cases.

Furthermore, Jim's original demo script emits it error with my stock 2.6.5
Python, but is silent with the patched trunk / 2.6 branch.

----------
nosy: +tseaver

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

From report at bugs.python.org  Mon May  3 17:08:43 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 03 May 2010 15:08:43 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272899323.62.0.940000955304.issue8576@psf.upfronthosting.co.za>


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

> I'm not sure if I agree that find_unused_port() should be removed though; it does serve a purpose in very rare corner cases.

It can serve a purpose in any number of cases.  My point is that it's *always* unreliable, though.  Any time you have any API that you want to test that requires a pre-allocated port number, you're going to have intermittent failures.  Such APIs are broken and should be fixed where possible and avoided otherwise.

----------

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

From report at bugs.python.org  Mon May  3 17:09:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 May 2010 15:09:42 +0000
Subject: [issue8601] bz2.BZ2File should support "with" protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272899382.13.0.969236459979.issue8601@psf.upfronthosting.co.za>


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

Indeed, and it was considered a feature request and thus is not appropriate for backport.  If you wish to see that decision changed I think you will need to appeal to python-dev.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.6 -Python 3.2

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

From report at bugs.python.org  Mon May  3 17:13:44 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 03 May 2010 15:13:44 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272899624.42.0.793248759289.issue8576@psf.upfronthosting.co.za>


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

I've applied the logging patch and checked into trunk (r80712).

----------

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

From report at bugs.python.org  Mon May  3 17:18:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 May 2010 15:18:04 +0000
Subject: [issue5565] Strange behavior when I logout() with IMAP4_SSL
In-Reply-To: <1238051545.58.0.380777960062.issue5565@psf.upfronthosting.co.za>
Message-ID: <1272899884.83.0.0292114475883.issue5565@psf.upfronthosting.co.za>


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

FWIW on my cisco firewalls the logs contain a lot of 'deny, no connection' messages for RST packets, probably coming from similar scenarios.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon May  3 17:27:52 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 03 May 2010 15:27:52 +0000
Subject: [issue1682942] ConfigParser support for alt delimiters
Message-ID: <1272900472.53.0.233740171576.issue1682942@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I'm afraid the patch no longer applies cleanly to the trunk, although
at least updating the docs should be easier now that they are converted
to ReStructuredText.

The tests in the patch for the new feature seem sensible.

----------
nosy: +tseaver

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

From report at bugs.python.org  Mon May  3 17:40:48 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 03 May 2010 15:40:48 +0000
Subject: [issue8581] Logging handlers do not handle double-closing very well
In-Reply-To: <1272659672.58.0.428458764285.issue8581@psf.upfronthosting.co.za>
Message-ID: <1272901248.44.0.197752966063.issue8581@psf.upfronthosting.co.za>


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

Fix checked into release26-maint (r80713).

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

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

From report at bugs.python.org  Mon May  3 17:57:10 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 03 May 2010 15:57:10 +0000
Subject: [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1272902230.94.0.195000958239.issue8600@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Is the message about threads emitted every time you run python under gdb? Does gdb work?  If so we should simply filter out the error message.

I'm attaching a patch which strips out that error message from stderr (assuming that I reformatted it for line-lengths correctly).

Does this fix things?

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17192/ignore-stderr-thread-noise.txt

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

From report at bugs.python.org  Mon May  3 18:09:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 16:09:19 +0000
Subject: [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272902959.52.0.579812478582.issue8593@psf.upfronthosting.co.za>


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

I've applied Eric's and Brian's suggestions and committed the patch to r80714 (py3k) and r80715 (3.1). Thank you!

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

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

From report at bugs.python.org  Mon May  3 18:11:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 16:11:00 +0000
Subject: [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1272903060.73.0.343497445185.issue8600@psf.upfronthosting.co.za>


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

The patch wasn't exactly good. Here is a working patch. Applying it reveals a couple of different failures, but I will open a separate issue.

----------
Added file: http://bugs.python.org/file17193/ignore-stderr-thread-noise2.txt

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

From report at bugs.python.org  Mon May  3 18:13:19 2010
From: report at bugs.python.org (Dan Buch)
Date: Mon, 03 May 2010 16:13:19 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272903199.41.0.10061154633.issue8604@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Mon May  3 18:14:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 16:14:53 +0000
Subject: [issue8605] gdb API issues
In-Reply-To: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>
Message-ID: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>


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

I now get the following failures in test_gdb:

======================================================================
FAIL: test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 599, in test_pyup_command
    $''')
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n$'

======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 613, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 129, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: 'Error occurred in Python command.\nError occurred in Python command.\n' != ''

======================================================================
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down"
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 628, in test_up_then_down
    $''')
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\n#3 Frame 0x805700, for file /home/antoine/cpython/__svn__/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n    print(42)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 10, in baz \\(args=\\(1, 2, 3\\)\\)\n    print\\(42\\)\n$'

======================================================================
FAIL: test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 634, in test_basic_command
    cmds_after_breakpoint=['py-bt'])
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 129, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: 'Error occurred in Python command.\n' != ''

======================================================================
FAIL: test_print_after_up (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 658, in test_print_after_up
    r".*\nlocal 'c' = 3\nlocal 'b' = 2\nlocal 'a' = 1\n.*")
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\nUnable to read information on python frame\nUnable to read information on python frame\nUnable to read information on python frame\n' did not match ".*\\nlocal 'c' = 3\\nlocal 'b' = 2\\nlocal 'a' = 1\\n.*"

======================================================================
FAIL: test_locals_after_up (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 684, in test_locals_after_up
    r".*\na = 1\nb = 2\nc = 3\n.*")
  File "/home/antoine/cpython/__svn__/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x4508a0: file Objects/object.c, line 330.\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x7ffff7535780, flags=1) at Objects/object.c:330\n330\t\treturn internal_print(op, fp, flags, 0);\n#7 (unable to read python frame information)\nUnable to read information on python frame\n' did not match '.*\\na = 1\\nb = 2\\nc = 3\\n.*'

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


Basically, it seems the Python API for gdb is a bit unstable or changing. Here is what manually trying the new commands produces:

(gdb) py-bt 
#4 (unable to read python frame information)
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1341, in invoke
    frame.print_summary()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1195, in print_summary
    pyop = self.get_pyop()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1168, in get_pyop
    return PyFrameObjectPtr.from_pyobject_ptr(f)
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 349, in from_pyobject_ptr
    return cls(gdbval)
TypeError: __init__() takes exactly 3 arguments (2 given)
Error occurred in Python command.

(gdb) py-up 
Traceback (most recent call last):
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1309, in invoke
    move_in_stack(move_up=True)
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1289, in move_in_stack
    iter_frame.print_summary()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1195, in print_summary
    pyop = self.get_pyop()
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 1168, in get_pyop
    return PyFrameObjectPtr.from_pyobject_ptr(f)
  File "/home/antoine/cpython/__svn__/python-gdb.py", line 349, in from_pyobject_ptr
    return cls(gdbval)
TypeError: __init__() takes exactly 3 arguments (2 given)
Error occurred in Python command.


$ gdb --version
GNU gdb (GDB) 7.1-1mdv2010.1 (Mandriva Linux release 2010.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-mandriva-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

----------
assignee: dmalcolm
components: Demos and Tools, Tests
messages: 104852
nosy: dmalcolm, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: gdb API issues
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May  3 18:40:20 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 03 May 2010 16:40:20 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272897319.9.0.939287466056.issue8586@psf.upfronthosting.co.za>
Message-ID: <4BDEFC6D.3010802@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Sorry, typing too fast:

   http://bugs.python.org/issue7443 - test.support.unlink issue on Windows platform

at least insofar as the issue applies to Windows. I imagine that the
OS X thingis completely different.

----------

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

From report at bugs.python.org  Mon May  3 18:59:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 16:59:10 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1272905950.06.0.0582011103179.issue7865@psf.upfronthosting.co.za>


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

Thanks for the patch! It was committed in r80720 (trunk), r80721 (2.6), r80722 (py3k), r80723 (3.1).

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

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

From report at bugs.python.org  Mon May  3 19:22:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 03 May 2010 17:22:00 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272907320.42.0.635903330287.issue8604@psf.upfronthosting.co.za>


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

Well, a context manager sounds overkill since we just want to write some content in a file (and nothing else during that context). 

I think a simple call is straightforward:

  shutil.atomic_write("foo", "contents", mode="wb")

----------

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

From report at bugs.python.org  Mon May  3 19:23:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 03 May 2010 17:23:00 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272907380.84.0.773932267408.issue8604@psf.upfronthosting.co.za>


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

Notice that "contents" could be replaced here by an iterator, that would return data to send to write()

----------

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

From report at bugs.python.org  Mon May  3 19:31:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 17:31:55 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272907320.42.0.635903330287.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272908055.21551.10.camel@localhost.localdomain>


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

> Well, a context manager sounds overkill since we just want to write
> some content in a file (and nothing else during that context). 

Using a context manager, though, is the recommended idiom to write
files. I think there's a value in remaining consistent. We don't want to
end up like PHP which has dozens of different idioms of doing similar
things.

----------

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

From report at bugs.python.org  Mon May  3 19:38:08 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 17:38:08 +0000
Subject: [issue8601] bz2.BZ2File should support "with" protocol per PEP 343
In-Reply-To: <1272869669.89.0.492897458524.issue8601@psf.upfronthosting.co.za>
Message-ID: <1272908288.96.0.199547084818.issue8601@psf.upfronthosting.co.za>


Matt Wartell <matt.wartell+pt at gmail.com> added the comment:

Sorry for the dup, and thanks for the patch. 

My patch for Module/bz2module.c was almost done - I learned a lot in the process, but foremost to check better for dups, first ;)

----------

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

From report at bugs.python.org  Mon May  3 19:42:32 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 03 May 2010 17:42:32 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272908552.9.0.396600831561.issue8604@psf.upfronthosting.co.za>


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

This idiom makes sense when you want to do some things with an open file, and replaces the usual try..finally idiom.

That's not what we want to do here. We want to write data in a file in a single step, in an atomic manner. 

Giving the ability to the developers to work in a context manager means that you potentially give them the ability to break this atomicity.

So I don't think the context manager idiom prevails, and should be avoided : shutil.atomic_write is asked to write a file, given some data, and don't return until it's done.

----------

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

From report at bugs.python.org  Mon May  3 19:48:50 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 03 May 2010 17:48:50 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272908930.17.0.189933575968.issue8604@psf.upfronthosting.co.za>


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

Considering that it's extremely difficult to implement this correctly and in a cross-platform way, I think it makes sense as a stdlib addition (though I'd add it as a method of a `path` type rather than to the "shell utilities" module ;).

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

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

From report at bugs.python.org  Mon May  3 19:51:54 2010
From: report at bugs.python.org (Bruce Frederiksen)
Date: Mon, 03 May 2010 17:51:54 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1272909114.58.0.832205017278.issue4806@psf.upfronthosting.co.za>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

I have also hit this error.  I went to report it but found it already entered (good news), but not resolved from nearly a year ago (bad news).

The error masked another bug that I had in my program and it took me quite awhile to figure out what the real problem was.

I use *generator arguments quite a lot, so was surprised to see the error.  So I, for one, can say that if you disable *generator arguments, you will break existing code.

If anybody cares, I have verified that this error also appears in Python2.5 and Python2.4 and am attempting to add python2.5 to the Versions list.  (And yes, *generators were allowed in Python2.4!)

Is this headed for resolution?  Progress on it seems to have stalled nearly a year ago.  Can I vote to revive this?

----------
nosy: +dangyogi
versions: +Python 2.5

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

From report at bugs.python.org  Mon May  3 19:54:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 03 May 2010 17:54:35 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272909275.29.0.620950460888.issue8604@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree that with the addition of the new requirement that it be an atomic write, it should be in a library.

I'd also do it as a context manager, since that's the more general case. distutils2 can either call the context manager version, or have a trivial function that calls the context manager.

----------

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

From report at bugs.python.org  Mon May  3 19:55:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 17:55:34 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272908552.9.0.396600831561.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272909470.21551.11.camel@localhost.localdomain>


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

> Giving the ability to the developers to work in a context manager
> means that you potentially give them the ability to break this
> atomicity.

AFAICT this doesn't make sense. The writing isn't atomic, the renaming
is.

----------

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

From report at bugs.python.org  Mon May  3 19:58:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 17:58:09 +0000
Subject: [issue665761] reduce() masks exception
Message-ID: <1272909489.9.0.485689702937.issue665761@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +needs review
stage: unit test needed -> patch review

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

From report at bugs.python.org  Mon May  3 20:03:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 May 2010 18:03:26 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
	mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1272909806.67.0.662394878761.issue4806@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +needs review
stage:  -> patch review

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

From report at bugs.python.org  Mon May  3 20:05:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 May 2010 18:05:09 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1272909909.88.0.118298517656.issue3720@psf.upfronthosting.co.za>


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

The fix works for 3.1.2, giving
TypeError: iter() returned non-iterator of type 'BadIterator'

Too late to patch 2.5. Is there any intention of patching 2.6 before its final bug-fix release, in a couple of months?

----------
keywords:  -needs review, patch
versions:  -Python 2.5, Python 3.0

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

From report at bugs.python.org  Mon May  3 20:11:18 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 18:11:18 +0000
Subject: [issue8535] passing optimization flags to the linker required
	for	builds with gcc -flto
In-Reply-To: <1272554414.26.0.979060528122.issue8535@psf.upfronthosting.co.za>
Message-ID: <4BDF11C1.4040202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Matthias Klose wrote:
> 
> Matthias Klose <doko at debian.org> added the comment:
> 
> my understanding is that the builder is allowed to overwrite OPT, but not BASECFLAGS.

The builder should actually be allowed to override the complete
CFLAGS and LDFLAGS settings, but for historic reasons, this is
currently not possible and you're right: OPT was meant to be overridden
by the user and BASECFLAGS is reserved for configure use.

Since just adding the CFLAGS to the linker invokation breaks on
various platforms (the linker doesn't expect compiler flags or
complains due to duplicate flags), this simple route will not work.

I suppose the best way to do this is by adding an extra check
to configure.in that tests whether the new GCC 4.5 option is supported
and also check whether CFLAGS can be passed to the
linker. If this test succeed, the configure script could then
add CFLAGS to the linker invokations or perhaps merge CFLAGS into
LDFLAGS.

----------

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

From report at bugs.python.org  Mon May  3 20:21:21 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 03 May 2010 18:21:21 +0000
Subject: [issue8604] Alias for distutils.file_util.write_file in e.g. shutils
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272910881.89.0.276471189263.issue8604@psf.upfronthosting.co.za>


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

@Antoine, @Eric: After some more thoughts a contextlib makes more sense.

I also have a use case for an atomic copytree() but I guess that can be an option in copytree()

----------

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

From report at bugs.python.org  Mon May  3 20:23:10 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 03 May 2010 18:23:10 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272910990.56.0.545986589509.issue8604@psf.upfronthosting.co.za>


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


----------
title: Alias for distutils.file_util.write_file in e.g. shutils -> Adding an atomic FS write API

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

From report at bugs.python.org  Mon May  3 20:40:25 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 03 May 2010 18:40:25 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1272912025.34.0.736951773325.issue8390@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Yes, I will soon have ;-) Please give me a few days...

----------

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

From report at bugs.python.org  Mon May  3 21:19:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 19:19:30 +0000
Subject: [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1272914370.81.0.189851117121.issue8600@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Mon May  3 21:21:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 19:21:38 +0000
Subject: [issue8605] gdb API issues
In-Reply-To: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>
Message-ID: <1272914498.29.0.0298759070374.issue8605@psf.upfronthosting.co.za>


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

See #8482 for the "Unable to read information on python frame" issue.

----------
nosy: +haypo

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

From report at bugs.python.org  Mon May  3 21:32:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 19:32:07 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272877379.47.0.536353580696.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BDF24B0.2090000@v.loewis.de>


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

> I think that we cannot decide correctly about fs*code() until we decided for os.environb.

Why is that? In msg104063, you claim that you want to create these
functions to deal with file names (not environment variables), in
msg104064, you claim that #8513 (which is about the program name in
subprocess) would benefit from these functions. Do these use cases
become invalid if os.environb becomes available?

----------

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

From report at bugs.python.org  Mon May  3 21:32:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 19:32:36 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1272915156.41.0.314496761557.issue8390@psf.upfronthosting.co.za>


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

A better fix is maybe to store fields as bytes, but it would break the compatibility and unicode is pratical in Python3.

----------

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

From report at bugs.python.org  Mon May  3 21:33:37 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 19:33:37 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272915217.87.0.39024425475.issue8603@psf.upfronthosting.co.za>


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

Can somebody please explain what problem is being solved with this patch?

----------

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

From report at bugs.python.org  Mon May  3 21:51:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 19:51:57 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1272916317.66.0.522502089775.issue8390@psf.upfronthosting.co.za>


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

I think it is helpful to read the pax specification here:

http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html

pax defines (IIUC) that all strings in a pax-compliant tar file are UTF-8 encoded. For the "invalid" option, they offer the alternatives bypass, rename, UTF-8, and write. It may be useful to provide the same options, in some form.

----------

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

From report at bugs.python.org  Mon May  3 21:59:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 19:59:10 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1272916750.35.0.358817120117.issue8390@psf.upfronthosting.co.za>


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

My patch changes test_uname_unicode() of test_tarfile for the GNU and ustar formats (but not PAX). In GNU and ustar formats, the fields can be encoded in any encoding, and may contain invalid byte sequences.

----------

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

From report at bugs.python.org  Mon May  3 22:12:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 20:12:10 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272917530.21.0.0788060792885.issue8514@psf.upfronthosting.co.za>


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

> Why is that? In msg104063, you claim that you want to create these
> functions to deal with file names (not environment variables)

Yes, but my os_path_fs_encode_decode-3.patch uses it in getenv() which is maybe a bad idea: os.environb may avoid this.

> in msg104064, you claim that #8513 (which is about the program name in
> subprocess) would benefit from these functions. Do these use cases
> become invalid if os.environb becomes available?

#8513 is also related to environment variables: subprocess._execute_child() calls os.get_exec_path() which search the PATH environment variable. It would be nice to support bytes environment variable in the env argument of Popen constructor (bytes key and/or value).

----------

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

From report at bugs.python.org  Mon May  3 22:14:56 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 03 May 2010 20:14:56 +0000
Subject: [issue8606] OSF  is not supported anymore
In-Reply-To: <1272917696.34.0.331615225862.issue8606@psf.upfronthosting.co.za>
Message-ID: <1272917696.34.0.331615225862.issue8606@psf.upfronthosting.co.za>


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

OSF* platform seems to be pretty dead. We are moving it to unsupported state, as documented in PEP11.

The first phase is Python 3.2: Configure will fail win OSF* platforms. This configuration failure will be trvivially reversible.

If nobody stands up to take care of OSF*, support will be removed in Python 3.3.

Discussion:

http://mail.python.org/pipermail/python-dev/2010-April/099718.html

http://mail.python.org/pipermail/python-dev/2010-May/099899.html

----------
assignee: jcea
messages: 104875
nosy: jcea
priority: normal
severity: normal
stage: committed/rejected
status: open
title: OSF  is not supported anymore
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May  3 22:18:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 20:18:27 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272917530.21.0.0788060792885.issue8514@psf.upfronthosting.co.za>
Message-ID: <4BDF2F90.5080904@v.loewis.de>


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

STINNER Victor wrote:
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Why is that? In msg104063, you claim that you want to create these
>> functions to deal with file names (not environment variables)
> 
> Yes, but my os_path_fs_encode_decode-3.patch uses it in getenv() which 
> is maybe a bad idea: os.environb may avoid this.

IIUC, that usage is an equivalent transformation, i.e. the code doesn't
change its behavior. It is mere refactorization.

So *if* these functions are accepted, this change is a good idea
regardless of the os.environb introduction (unless I'm missing
something, and there is indeed a behavior change).

>> in msg104064, you claim that #8513 (which is about the program name in
>> subprocess) would benefit from these functions. Do these use cases
>> become invalid if os.environb becomes available?
> 
> #8513 is also related to environment variables: subprocess._execute_child() 
> calls os.get_exec_path() which search the PATH environment variable.
> It would be nice to support bytes environment variable in the env
> argument of Popen constructor (bytes key and/or value).

I still fail to see why this would make this issue block on the
os.environb introduction. Whether this gets introduced or not, the
program name issue remains, no?

----------

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

From report at bugs.python.org  Mon May  3 22:25:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 20:25:57 +0000
Subject: [issue8606] OSF  is not supported anymore
In-Reply-To: <1272917696.34.0.331615225862.issue8606@psf.upfronthosting.co.za>
Message-ID: <1272918357.49.0.98763275974.issue8606@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Mon May  3 22:27:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 20:27:28 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272915217.87.0.39024425475.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BDF31AD.7070302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> Can somebody please explain what problem is being solved with this patch?

The way os.environ is currently set up on Unix breaks applications
using the environment to pass data to helper applications.

Please see the discussion on http://bugs.python.org/issue8514
for details.

----------

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

From report at bugs.python.org  Mon May  3 22:30:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 20:30:20 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF31AD.7070302@egenix.com>
Message-ID: <4BDF325A.2080609@v.loewis.de>


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

> Please see the discussion on http://bugs.python.org/issue8514
> for details.

I can't see any report of actual breakage in that report, only claims of
potential breakage (with no supporting examples)

----------

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

From report at bugs.python.org  Mon May  3 22:36:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 20:36:25 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272918985.13.0.162504772818.issue8603@psf.upfronthosting.co.za>


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

An issue was opened 2 years ago: "It was brought up in a discussion of sending non-ASCii data to a CGI-WSGI script where the data would be transferred via os.environ." => #4006 (closed as "wont fix").

----------

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

From report at bugs.python.org  Mon May  3 22:45:21 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 20:45:21 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272918985.13.0.162504772818.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BDF35DD.5010607@v.loewis.de>


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

> An issue was opened 2 years ago: "It was brought up in a discussion
> of sending non-ASCii data to a CGI-WSGI script where the data would
> be transferred via os.environ." => #4006 (closed as "wont fix").

Fortunately, that issue could now be reconsidered as "fixed"; the
example in the report (msg74118) now works correctly - thanks to PEP
383. So I still fail to see the problem.

----------

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

From report at bugs.python.org  Mon May  3 22:51:00 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 03 May 2010 20:51:00 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272919860.7.0.98637305791.issue8586@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I cannot reproduce this on my 10.6.3 machine either running the full test suite, or running:

./python.exe Lib/test/test_imp.py
./python.exe -m unittest test.test_imp

----------
resolution:  -> works for me

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

From report at bugs.python.org  Mon May  3 22:54:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 May 2010 20:54:29 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272920069.34.0.1962325966.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hmm... happens reliably for me.

----------

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

From report at bugs.python.org  Mon May  3 23:04:34 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 21:04:34 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF325A.2080609@v.loewis.de>
Message-ID: <4BDF3A5E.6080101@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> Please see the discussion on http://bugs.python.org/issue8514
>> for details.
> 
> I can't see any report of actual breakage in that report, only claims of
> potential breakage (with no supporting examples)

Set your CODESET to ASCII and watch the surrogate escaping
begin... seriously, Martin, if you've ever worked with CGI
or WSGI or FastCGI or SCGI or any of the many other protocols
that use the OS environment for passing data between processes,
it doesn't take much imagination to come up with examples
that fail left and right.

Here's one (RFC 3875, sections 4.1.7 and 4.1.5):

LANG = 'en_US.utf8'
CONTENT_TYPE = 'application/x-www-form-urlencoded'
QUERY_STRING = 'type=example&name=L?wis'
PATH_INFO = '/home/l??wis/bin/mycgi.py'

(HTML uses Latin-1 as default encoding and so do many of the
 protocols invented for it !)

The file system encoding simply doesn't relate to the OS
environment at all - it's just a collection of name=value mappings
with no explicit encoding information. It may be a good guess,
but that's it.

----------

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

From report at bugs.python.org  Mon May  3 23:10:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 21:10:42 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF3A5E.6080101@egenix.com>
Message-ID: <4BDF3BCF.6070109@v.loewis.de>


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

> Set your CODESET to ASCII and watch the surrogate escaping
> begin... seriously, Martin, if you've ever worked with CGI
> or WSGI or FastCGI or SCGI or any of the many other protocols
> that use the OS environment for passing data between processes,
> it doesn't take much imagination to come up with examples
> that fail left and right.
> 
> Here's one (RFC 3875, sections 4.1.7 and 4.1.5):
> 
> LANG = 'en_US.utf8'
> CONTENT_TYPE = 'application/x-www-form-urlencoded'
> QUERY_STRING = 'type=example&name=L?wis'
> PATH_INFO = '/home/l??wis/bin/mycgi.py'

I still don't see a *failure* here. AFAICT, it all works correctly.
In particular, I fail to see the advantage of using bytes over using
escaped strings, in terms of correctness. I'm even skeptical that there
is an advantage in terms of usability (and if there is, I'd like to see
a demonstration of that, as well).

----------

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

From report at bugs.python.org  Mon May  3 23:14:53 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 03 May 2010 21:14:53 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272921293.7.0.336540408554.issue8586@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

How odd.  I'm on r80727 in py3k.

----------

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

From report at bugs.python.org  Mon May  3 23:31:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 21:31:02 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF3A5E.6080101@egenix.com>
Message-ID: <4BDF4091.5000702@v.loewis.de>


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

> Here's one (RFC 3875, sections 4.1.7 and 4.1.5):
> 
> LANG = 'en_US.utf8'
> CONTENT_TYPE = 'application/x-www-form-urlencoded'
> QUERY_STRING = 'type=example&name=L?wis'
> PATH_INFO = '/home/l??wis/bin/mycgi.py'
> 
> (HTML uses Latin-1 as default encoding and so do many of the
>  protocols invented for it !)

BTW, I think you are misinterpreting the RFC. It doesn't actually say
that QUERY_STRING is Latin-1 encoded, but instead, it says

"the details of the parsing, reserved characters and support for non
US-ASCII characters depends on the context"

Latin-1 is only given as a possible example. Apache passes the URL from
the HTTP request unescaped; browsers will likely CGI-escape it. So most
likely, it will be

QUERY_STRING = 'type=example&name=L%F6wis'
or
QUERY_STRING = 'type=example&name=L%C3%B6wis'

IMO, applications are much better off to consider QUERY_STRING as a
character string.

----------

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

From report at bugs.python.org  Mon May  3 23:35:21 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 03 May 2010 21:35:21 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272922521.82.0.114807203391.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yep, same here.

----------

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

From report at bugs.python.org  Mon May  3 23:38:44 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 03 May 2010 21:38:44 +0000
Subject: [issue8606] OSF  is not supported anymore
In-Reply-To: <1272917696.34.0.331615225862.issue8606@psf.upfronthosting.co.za>
Message-ID: <1272922724.12.0.257995989551.issue8606@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am unsupporting OSF* systems. If that is too much to deprecate, change it to deprecate only OSF1.

Commit at r80728.

----------
resolution:  -> accepted
status: open -> closed
type:  -> feature request

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

From report at bugs.python.org  Tue May  4 00:02:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 22:02:07 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF3BCF.6070109@v.loewis.de>
Message-ID: <4BDF47DB.8020105@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> Set your CODESET to ASCII and watch the surrogate escaping
>> begin... seriously, Martin, if you've ever worked with CGI
>> or WSGI or FastCGI or SCGI or any of the many other protocols
>> that use the OS environment for passing data between processes,
>> it doesn't take much imagination to come up with examples
>> that fail left and right.
>>
>> Here's one (RFC 3875, sections 4.1.7 and 4.1.5):
>>
>> LANG = 'en_US.utf8'
>> CONTENT_TYPE = 'application/x-www-form-urlencoded'
>> QUERY_STRING = 'type=example&name=L?wis'
>> PATH_INFO = '/home/l??wis/bin/mycgi.py'
> 
> I still don't see a *failure* here. AFAICT, it all works correctly.

Your name will end up being partially escaped as surrogate:

'L\udcf6wis'

Further processing will fail, since the application would
correctly assume that the data is Latin-1 only (see the RFC):

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'latin-1' codec can't encode character '\udcf6' in position 1: ordinal not in
range(256)

> In particular, I fail to see the advantage of using bytes over using
> escaped strings, in terms of correctness. I'm even skeptical that there
> is an advantage in terms of usability (and if there is, I'd like to see
> a demonstration of that, as well).

The use of the 'surrogateescape' error handler modifies the
encoding used for the decoding of the bytes data and does this
implicitly.

This works fine as long as the data is only used *as reference* to
some entity (e.g. as in a file name) and manipulation of that
data is limited to concatenation and slicing. Things that you do
with file names and paths.

It doesn't work if an application tries to work *with* the data,
e.g. tries to convert it, parse it, decode it, etc. The reason is
that information included by the use of the 'surrogateescape'
error handler is lost along the way and this then causes data
corruption.

----------

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

From report at bugs.python.org  Tue May  4 00:02:40 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 03 May 2010 22:02:40 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272924160.92.0.631269906177.issue8576@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Any time you have any API that you want to test that requires a 
> pre-allocated port number, you're going to have intermittent failures.  
> Such APIs are broken and should be fixed where possible and avoided 
> otherwise.

You mean that socket.create_connection(), httplib (issue 3972) and ftplib should or should have used a different API to implement their "source_address" option?

----------

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

From report at bugs.python.org  Tue May  4 00:03:00 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 03 May 2010 22:03:00 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272924180.68.0.749722559903.issue8576@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------

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

From report at bugs.python.org  Tue May  4 00:04:10 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 03 May 2010 22:04:10 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272924250.06.0.853692249796.issue8576@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Any time you have any API that you want to test that requires a 
> pre-allocated port number, you're going to have intermittent failures.  
> Such APIs are broken and should be fixed where possible and avoided 
> otherwise.

You mean that socket.create_connection(), httplib (issue 3972) and ftplib (issue 8594) should have used a different API to implement their "source_address" option?

----------

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

From report at bugs.python.org  Tue May  4 00:08:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 22:08:16 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272924250.06.0.853692249796.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272924637.21551.12.camel@localhost.localdomain>


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

> You mean that socket.create_connection(), httplib (issue 3972) and
> ftplib (issue 8594) should have used a different API to implement
> their "source_address" option?

                  source_address=("192.168.0.2", 0))
>>> s.getsockname()
('192.168.0.2', 40496)

----------

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

From report at bugs.python.org  Tue May  4 00:08:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 22:08:49 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272924529.74.0.409015608994.issue8576@psf.upfronthosting.co.za>


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

Roundup ate my code. I meant:

>>> s = socket.create_connection(("python.org", 80), source_address=("192.168.0.2", 0))
>>> s.getsockname()
('192.168.0.2', 40496)

----------

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

From report at bugs.python.org  Tue May  4 00:08:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 22:08:55 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272924535.93.0.944937821249.issue8576@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------

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

From report at bugs.python.org  Tue May  4 00:11:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 22:11:23 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF47DB.8020105@egenix.com>
Message-ID: <4BDF4A06.1020603@v.loewis.de>


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

> Your name will end up being partially escaped as surrogate:
> 
> 'L\udcf6wis'
> 
> Further processing will fail

That depends on the further processing, no?

> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> UnicodeEncodeError: 'latin-1' codec can't encode character '\udcf6' in position 1: ordinal not in
> range(256)

Where did you get this error from?

> It doesn't work if an application tries to work *with* the data,
> e.g. tries to convert it

Converting it to what?

> parse it

Parsing will work fine.

> decode it

It's a string. You shouldn't decode it.

> The reason is
> that information included by the use of the 'surrogateescape'
> error handler is lost along the way and this then causes data
> corruption.

And how would that not happen if it was bytes? The problems you describe
were one of the primary motivations to switch to Unicode: it's *byte*
strings that have these problems.

----------

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

From report at bugs.python.org  Tue May  4 00:16:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 03 May 2010 22:16:18 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1272924978.69.0.370618086121.issue8604@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Tue May  4 00:20:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 22:20:49 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272925249.12.0.903710490314.issue8603@psf.upfronthosting.co.za>


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

> Can somebody please explain what problem is being solved with this patch?

The problem is that we don't have reliable algorithm to get the encoding of each environment variable. We cannot ensure that all variables are encoded "correctly".

Using os.getenvb(), you can decode the string using the right encoding (which may be different for each variable).

Marc proposed os.getenv(key, encoding=...) but I don't like this solution: you have to split correctly all unicode things and all bytes things. You should have the choice to keep environment unchanged, as byte strings, and manipulate only byte strings, or to use the classic API (unicode only, os.getenv, os.environ(), ....).

os.environb and os.getenvb() will be required to applications in real world application supporting all applications and misconfigured environments. Python3 shouldn't try to fix misconfigured systems but leave this problem to the developer.

----------

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

From report at bugs.python.org  Tue May  4 00:31:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 22:31:07 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272925867.75.0.570614710694.issue8514@psf.upfronthosting.co.za>


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

> IIUC, that usage is an equivalent transformation, i.e. the code doesn't
> change its behavior. It is mere refactorization.

I changed os.getenv() to accept byte string key (in a previous commit), but I don't like this hack. If we have os.environb, os.getenv() shouldn't support bytes anymore (but use str only, as before).

--

I worked a little more on fsencode()/os.environb, trying to fix all issues. fsdecode() is no more needed if we have os.environb, and fsencode() can be simplified to:

  def fsencode(value):
     return value.encode(sys.getfilesystemencoding(), 'surrogateescape')

fsdecode() leads to mojibake.

----------

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

From report at bugs.python.org  Tue May  4 00:34:29 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 03 May 2010 22:34:29 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272926069.54.0.750299356694.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Added file: http://bugs.python.org/file17194/nir-ccbench-xp32.log

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

From report at bugs.python.org  Tue May  4 00:35:02 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 03 May 2010 22:35:02 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272926102.28.0.214192500249.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file16967/bfs.patch

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

From report at bugs.python.org  Tue May  4 00:36:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 22:36:18 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272925249.12.0.903710490314.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BDF4FDF.9030806@v.loewis.de>


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

> Using os.getenvb(), you can decode the string using the right
> encoding (which may be different for each variable).

Ok. If that's the motivation, the documentation should make that
clear (there isn't any documentation in the patch, anyway). I'm
worried that people start processing the bytes as-is (i.e. without
decoding them), and then start complaining that this and that library
doesn't support bytes. Then they start complaining that you can't
mix bytes and Unicode...

I also worry that people won't get it right any better than Python:
when they find that it doesn't work, they ask what to do, and people
will tell them decode with "iso-8859-1" (say). Then they do that,
and end up in moji-bake the next day.

----------

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

From report at bugs.python.org  Tue May  4 00:38:18 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 May 2010 22:38:18 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF4091.5000702@v.loewis.de>
Message-ID: <4BDF5054.4050102@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> Here's one (RFC 3875, sections 4.1.7 and 4.1.5):
>>
>> LANG = 'en_US.utf8'
>> CONTENT_TYPE = 'application/x-www-form-urlencoded'
>> QUERY_STRING = 'type=example&name=L?wis'
>> PATH_INFO = '/home/l??wis/bin/mycgi.py'
>>
>> (HTML uses Latin-1 as default encoding and so do many of the
>>  protocols invented for it !)
> 
> BTW, I think you are misinterpreting the RFC. It doesn't actually say
> that QUERY_STRING is Latin-1 encoded, but instead, it says
> 
> "the details of the parsing, reserved characters and support for non
> US-ASCII characters depends on the context"

Please read on:

"""
   For example, form submission from an HTML
   document [18] uses application/x-www-form-urlencoded encoding, in
   which the characters "+", "&" and "=" are reserved, and the ISO
   8859-1 encoding may be used for non US-ASCII characters.
"""

I could have also given you an example using 'multipart/form-data'
in which each part uses a different encoding or even sends binary
data by means of 'Content-Transfer-Encoding: binary'

These are not made up examples, they do occur in the real world for
which we are coding.

> Latin-1 is only given as a possible example. Apache passes the URL from
> the HTTP request unescaped; browsers will likely CGI-escape it. So most
> likely, it will be
> 
> QUERY_STRING = 'type=example&name=L%F6wis'
> or
> QUERY_STRING = 'type=example&name=L%C3%B6wis'
>
> IMO, applications are much better off to consider QUERY_STRING as a
> character string.

Believe me, I've been working with HTML, forms, web apps, etc.
for almost 20 years now. In the real world, your application has
to cope with any kind of data in QUERY_STRING.

And this is just one example of how the OS environment can
be used, e.g. to provide the user meta-data, license data,
company names.

Even if these all use UTF-8, a user might still want to stick
to ASCII as her CODESET and then all her Python application would
start to fail at first sight of a French accent or German
Umlaut.

PEP 383 is nice for file names and paths, but it's unfortunately
not going to save the world...

----------

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

From report at bugs.python.org  Tue May  4 00:44:13 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 03 May 2010 22:44:13 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1272926653.21.0.533480020863.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I updated bfs.patch with improvements on Windows XP. 

The update disables priority boosts associated with the scheduler condition on Windows for CPU bound threads.

Here is a link to ccbench results:
http://bugs.python.org/file17194/nir-ccbench-xp32.log

Summary:

Windows XP 32bit q9400 2.6GHz Release build (no PG optimizations).
Test runs in background, ccbench modified to run both bz2 and sha1.

bfs.patch - seems to behave.

gilinter2.patch
single core: high latency, low IO bandwidth.

dabeaz_gil.patch 
single core: low IO bandwidth.
4 cores: throughput threads starvation (balance), some latency, low IO bandwidth.

----------
Added file: http://bugs.python.org/file17195/bfs.patch

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

From report at bugs.python.org  Tue May  4 00:51:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 May 2010 22:51:47 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272927107.58.0.56716994623.issue8603@psf.upfronthosting.co.za>


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

> I also worry that people won't get it right any better than Python (...)

Developers coming from Python2 will continue to use os.getenv() and will not worry about encoding, and maybe not notice that the result is now unicode (and not more a byte string).

I think that a developer will only switch to os.getenvb() if he/she has troubles with the encodings.

----------

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

From report at bugs.python.org  Tue May  4 00:54:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 03 May 2010 22:54:30 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272927107.58.0.56716994623.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BDF5424.6030108@v.loewis.de>


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

> I think that a developer will only switch to os.getenvb() if he/she
> has troubles with the encodings.

That's indeed a positive feature of this proposed change.

----------

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

From report at bugs.python.org  Tue May  4 01:01:01 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 03 May 2010 23:01:01 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272927661.79.0.950094957315.issue8557@psf.upfronthosting.co.za>


Changes by Dave Abrahams <dave at boostpro.com>:


Removed file: http://bugs.python.org/file17142/probe.py

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

From report at bugs.python.org  Tue May  4 01:02:02 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 03 May 2010 23:02:02 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272927722.39.0.719538269743.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

Not to appear impatient, but...<bump>.
It's a fairly tidy answer, I think :-)

----------

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

From report at bugs.python.org  Tue May  4 01:03:45 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 03 May 2010 23:03:45 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1272927825.13.0.963947746457.issue3620@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Adding this:

    def handle_error(self):
        raise

...to SimSMTPChannel class would help to provide a clearer error message to understand where exactly EBADF comes from, altough I think this was an old asyncore bug which have already been fixed.
Is this still reproducible on Python 3.2?

----------

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

From report at bugs.python.org  Tue May  4 01:37:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 May 2010 23:37:50 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272929870.02.0.551609090762.issue8557@psf.upfronthosting.co.za>


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

Sorry for my Windows ignorance, but if CreateProcess ignores the PATH, how does updating the PATH fix the problem?

----------

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

From report at bugs.python.org  Tue May  4 02:25:10 2010
From: report at bugs.python.org (Robin Dunn)
Date: Tue, 04 May 2010 00:25:10 +0000
Subject: [issue8607] OSX: duplicate -arch flags in CFLAGS breaks sysconfig
In-Reply-To: <1272932709.85.0.263067973339.issue8607@psf.upfronthosting.co.za>
Message-ID: <1272932709.85.0.263067973339.issue8607@psf.upfronthosting.co.za>


New submission from Robin Dunn <robin at alldunn.com>:

In Python 2.7b1, building on OSX 10.6 with this configure command:

export CC=gcc-4.0
export CXX=g++-4.0
export MACOSX_DEPLOYMENT_TARGET=10.4
../configure \
	--with-universal-archs=32-bit \
	--enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk \
	--enable-framework 


Results in these lines in Makefile:

BASECFLAGS=	-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  -fno-common -dynamic
CFLAGS=		$(BASECFLAGS) -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk  $(OPT) $(EXTRA_CFLAGS)


Then later on in the build the sysconfig module uses the -arch flags in CFLAGS but is not able to find a match because of the extra set of values, and the build fails with this exception:

Traceback (most recent call last):
  File "./../Lib/site.py", line 542, in <module>
    main()
  File "./../Lib/site.py", line 521, in main
    addbuilddir()
  File "./../Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/projects/Python-2.7b1/Lib/sysconfig.py", line 646, in get_platform
    "Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1

----------
components: Build
messages: 104905
nosy: robind
priority: normal
severity: normal
status: open
title: OSX: duplicate -arch flags in CFLAGS breaks sysconfig
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue May  4 02:29:46 2010
From: report at bugs.python.org (Andrew Straw)
Date: Tue, 04 May 2010 00:29:46 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1272932986.13.0.890086128081.issue1054967@psf.upfronthosting.co.za>


Andrew Straw <astraw at users.sourceforge.net> added the comment:

I have moved the recent discussion on stdeb to a thread on the distutils-sig.

----------

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

From report at bugs.python.org  Tue May  4 02:57:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 00:57:05 +0000
Subject: [issue8607] OSX: duplicate -arch flags in CFLAGS breaks sysconfig
In-Reply-To: <1272932709.85.0.263067973339.issue8607@psf.upfronthosting.co.za>
Message-ID: <1272934625.87.0.181522770371.issue8607@psf.upfronthosting.co.za>


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

This is a duplicate of issue 8366.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> OS X universal builds fail on 2.7b1 and py3k with "Don't know machine value for archs"

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

From report at bugs.python.org  Tue May  4 03:22:56 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 01:22:56 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272936176.71.0.419525396643.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I'm probably as ignorant as you are of Windows issues. I just know what my experiments tell me: if you force the contents of any explicit 'env' argument into os.environ before calling Popen, you get the same behavior as on *nix.

----------

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

From report at bugs.python.org  Tue May  4 04:37:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 02:37:56 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272940676.99.0.859105767325.issue8557@psf.upfronthosting.co.za>


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

Well, it wouldn't be the first time the microsoft docs were wrong.

There are two questions here: (1) is this behavior consistent across all microsoft platforms we support?  (2) is this *change* in behavior of Popen acceptable?

For (1) we need a unit test added to the subprocess unit tests that can check this.

For (2)...well, I think it would be good for the behavior to be as consistent as practical, so I'd be in favor.  We need some second opinions, though, to make sure we aren't overlooking some negative consequence.  I'm also not sure that this qualifies as a bug fix, so it may only be possible to get it into 3.2, assuming it is acceptable.

Note that I have not tested your program on Windows myself, I'm taking your word for it that it works ;)  I'll be more inclined to test things if the tests are in the form of unit tests, which should be much easier to understand than your test program.

----------

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

From report at bugs.python.org  Tue May  4 04:39:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 02:39:14 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1272940754.93.0.94443493171.issue3620@psf.upfronthosting.co.za>


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

If it would provide clearer error message in cases of failure, it sounds like a reasonable thing to add whether or not the failure in this issue is still happening.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue May  4 05:50:29 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 May 2010 03:50:29 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1272945029.87.0.691516636191.issue8404@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r80749 and r80751 (for py3k).

Thank you!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue May  4 07:38:41 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 05:38:41 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272940676.99.0.859105767325.issue8557@psf.upfronthosting.co.za>
Message-ID: <m2k4rkql8u.wl%dave@boostpro.com>


Dave Abrahams <dave at boostpro.com> added the comment:

R. David Murray wrote:
> There are two questions here: (1) is this behavior consistent across all microsoft platforms we support?  

I'll be honest: I don't know.

> (2) is this *change* in behavior of Popen acceptable?

I don't know that either.

> I'll be more inclined to
> test things if the tests are in the form of unit tests, which should
> be much easier to understand than your test program.

I guess no good deed goes unpunished ;-)

I also guess that whether you think unit tests will be easier to
understand depends on what kind of information you expect to glean
from the code.  My script was designed to probe for all
inconsistencies between ?doze and POSIX behaviors, and it is more
revealing in that respect than a unit test would be.  The unit test
that would prompt the particular code change I'm suggesting would look
more like:

    put directory X in the env argument's PATH (but not in os.environ)
    attempt to launch X/some_executable as simply ?some_executable?
    assert that X/some_executable actually ran

I don't know what Popen's unit tests look like, and to be honest,
right now I just don't have any more time to pour into this particular
issue.  Even if it doesn't get fixed in Python I'm going to be using
my wrapper for uniformity.  I hope everything I've done so far is
useful to the community but if not, I still have what I need.

----------

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

From report at bugs.python.org  Tue May  4 10:51:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 04 May 2010 08:51:20 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BDF4A06.1020603@v.loewis.de>
Message-ID: <4BDFE002.4000101@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> Your name will end up being partially escaped as surrogate:
>>
>> 'L\udcf6wis'
>>
>> Further processing will fail
> 
> That depends on the further processing, no?
> 
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> UnicodeEncodeError: 'latin-1' codec can't encode character '\udcf6' in position 1: ordinal not in
>> range(256)
> 
> Where did you get this error from?

The roundup email interface must have eaten this
first line of the traceback: >>> _.encode('latin-1')

>> It doesn't work if an application tries to work *with* the data,
>> e.g. tries to convert it
> 
> Converting it to what?
> 
>> parse it
> 
> Parsing will work fine.
> 
>> decode it
> 
> It's a string. You shouldn't decode it.
>
>> The reason is
>> that information included by the use of the 'surrogateescape'
>> error handler is lost along the way and this then causes data
>> corruption.
> 
> And how would that not happen if it was bytes? The problems you describe
> were one of the primary motivations to switch to Unicode: it's *byte*
> strings that have these problems.

Martin, it's obvious that you are not even trying to understand
what I'm saying. That's not a good basis for discussion.

----------

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

From report at bugs.python.org  Tue May  4 10:58:07 2010
From: report at bugs.python.org (Torsten Marek)
Date: Tue, 04 May 2010 08:58:07 +0000
Subject: [issue8608] fix_import prefixes "." to already relative imports
In-Reply-To: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>
Message-ID: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>


New submission from Torsten Marek <shlomme at gmx.net>:

The fixer for absolute -> relative imports prefixes "." to already relative imports, i.e. 

    from . import something

will be converted into 

    from .. import something

if something.py exists. This of course will raise an exception on import or introduce subtle bugs if something exists in ..

I've attached a patch against 2to3 head which addresses this problem.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: fix-no-prefix-relative-import.diff
keywords: patch
messages: 104914
nosy: shlomme
priority: normal
severity: normal
status: open
title: fix_import prefixes "." to already relative imports
type: behavior
Added file: http://bugs.python.org/file17196/fix-no-prefix-relative-import.diff

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

From report at bugs.python.org  Tue May  4 11:00:17 2010
From: report at bugs.python.org (Torsten Marek)
Date: Tue, 04 May 2010 09:00:17 +0000
Subject: [issue8608] fix_import prefixes "." to already relative imports
In-Reply-To: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>
Message-ID: <1272963617.43.0.870681652545.issue8608@psf.upfronthosting.co.za>


Torsten Marek <shlomme at gmx.net> added the comment:

This file contains the same patch, but as a mercurial revision bundle.

----------

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

From report at bugs.python.org  Tue May  4 11:01:49 2010
From: report at bugs.python.org (Torsten Marek)
Date: Tue, 04 May 2010 09:01:49 +0000
Subject: [issue8608] fix_import prefixes "." to already relative imports
In-Reply-To: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>
Message-ID: <1272963709.19.0.841615899135.issue8608@psf.upfronthosting.co.za>


Torsten Marek <shlomme at gmx.net> added the comment:

Forgot the file name last time.

----------
Added file: http://bugs.python.org/file17197/fix-no-prefix-relative-import.bundle

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

From report at bugs.python.org  Tue May  4 11:47:22 2010
From: report at bugs.python.org (Nico)
Date: Tue, 04 May 2010 09:47:22 +0000
Subject: [issue8609] itertools: problem with nested groupby, list()
In-Reply-To: <1272966442.26.0.576520629253.issue8609@psf.upfronthosting.co.za>
Message-ID: <1272966442.26.0.576520629253.issue8609@psf.upfronthosting.co.za>


New submission from Nico <nico.schloemer at gmail.com>:

Hi,

I ran into a bit of an unexpected issue here with itertools.

I need to say that I discovered itertools only recently, and that maybe my way of approaching the problem is "not what I want to do". If you think this may be the case, please let me know.

Anyway, the problem is the following:
I have a list of dictionaries, something like

[ { "a": 1, "b": 1, "c": 3 },
  { "a": 1, "b": 1, "c": 4 },
  ...
]

and I'd like to iterate through all items with, e.g., "a":1. What I do is sort and then groupby,

my_list.sort( key=operator.itemgetter('a') )
my_list_grouped = itertools.groupby( my_list, operator.itemgetter('a') )

and then just very simply iterate over my_list_grouped,

for my_item in my_list_grouped:
    # do something with my_item[0], my_item[1]

Now, inside this loop I'd like to again iterate over all items with the same 'b'-value -- no problem, just do the above inside the loop:

for my_item in my_list_grouped:
        # group by keyword "b"
        my_list2 = list( my_item[1] )
        my_list2.sort( key=operator.itemgetter('b') )
        my_list_grouped = itertools.groupby( my_list2, operator.itemgetter('b') )
        for e in my_list_grouped:
            # do something with e[0], e[1]

That seems to work all right.

Now, the problem occurs when this all is wrapped into an outer loop, such as

for k in [ 'first pass', 'second pass' ]:
    for my_item in my_list_grouped:
    # bla, the above

To be able to iterate more than once through my_list_grouped, I have to convert it into a list first, so outside all loops, I go like

my_list.sort( key=operator.itemgetter('a') )
my_list_grouped = itertools.groupby( my_list, operator.itemgetter('a') )
my_list_grouped = list( my_list_grouped )

This, however, makes it impossible to do the inner sort and groupby-operation; you just get the very first element, and that's it.

An example file is attached.

Is there anything that I can do to debug?

Cheers,
Nico

----------
components: None
files: iterator-test.py
messages: 104917
nosy: nicki
priority: normal
severity: normal
status: open
title: itertools: problem with nested groupby, list()
versions: Python 2.6
Added file: http://bugs.python.org/file17198/iterator-test.py

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

From report at bugs.python.org  Tue May  4 11:58:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 09:58:49 +0000
Subject: [issue8609] itertools: problem with nested groupby, list()
In-Reply-To: <1272966442.26.0.576520629253.issue8609@psf.upfronthosting.co.za>
Message-ID: <1272967129.23.0.600663096346.issue8609@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You'd be better off asking this on the python mailing list http://mail.python.org/mailman/listinfo/python-list (or in some other forum);  this tracker is for reporting bugs in Python itself, not bugs in code written in Python.

[The problem you're encountering here is that you can only iterate over the return of itertools.groupby once.  That's by design, though:  it's not a Python bug.]

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue May  4 12:03:46 2010
From: report at bugs.python.org (Nico)
Date: Tue, 04 May 2010 10:03:46 +0000
Subject: [issue8609] itertools: problem with nested groupby, list()
In-Reply-To: <1272966442.26.0.576520629253.issue8609@psf.upfronthosting.co.za>
Message-ID: <1272967426.45.0.736723909922.issue8609@psf.upfronthosting.co.za>


Nico <nico.schloemer at gmail.com> added the comment:

Okay, thanks for the hint.
Closing as invalid.

----------

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

From report at bugs.python.org  Tue May  4 12:49:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 10:49:51 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1272970191.2.0.239428377439.issue8603@psf.upfronthosting.co.za>


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

New version of my patch, which looks much better. Summary:

  Issue #8603: Create os.environb and os.getenvb() on POSIX system.
  os.unsetenv() encodes str argument using file system encoding and
  surrogateescape error handler (instead of utf8/strict), and accept bytes.

Changes with my previous patch:

 - update os module documentation
 - os.getenv() only accepts str, os.getenvb() only accepts bytes (to avoid mojibake)
 - fix test_environb() of test_os for ASCII locale
 - fix os.putenv() if key is an unicode string: use the string encoded to bytes as key for posix_putenv_garbage
 - _Envion.__setitem__() encodes the key and value before calling putenv()
 - _Environ.__delitem__() encodes the key before calling unsetenv()
 - create a temporary function to create os.environ (to use temporary variables like encode, decode, keymap, data)
 - annotation types in os.getenv() and os.getenvb()
 - remove fsencode()/fsdecode() from the patch and don't touch os._execvpe() (will be fixed in other issues)
 - putenv() uses PyBytes_GET_SIZE() instead of strlen()

----------
Added file: http://bugs.python.org/file17199/os_environb-2.patch

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

From report at bugs.python.org  Tue May  4 12:56:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 10:56:29 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1272970589.14.0.111884847023.issue8514@psf.upfronthosting.co.za>


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

I think that fsencode() (and fsdecode()) should be specific to POSIX. I don't know any good reason to encode a nice and correctly encoded unicode string to the ugly MBCS "encoding".

----------

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

From report at bugs.python.org  Tue May  4 13:10:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 11:10:41 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1272971441.45.0.353328936214.issue8513@psf.upfronthosting.co.za>


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

Bytes program name problem should be splitted in two parts:

 (a) subprocess.call([b'env']) and subprocess.call([b'env'], env={'PATH': '/usr/bin'}): bytes program and unicode environ
 (b) bytes program and bytes environ

Part (a)
--------

(a) would benefit from the creation of os(.path).fsencode() function (issue #8514).

Part (b)
--------

If the creation of os.environb is accepted (#8603), I think that subprocess should also be modified to support pure bytes environ. Mix bytes and unicode variables in env would lead to mojibake and headaches.

So I propose the creation of an "envb" (environment bytes) argument to Popen constructor. (b) would be written as:

   subprocess.call([b'env'], envb={b'PATH': b'/usr/bin'})

or

   envb = os.environb.copy()
   envb[b'PATH'] = b'/usr/bin'
   subprocess.call([b'env'], envb=envb)

(and it will not be possible to define env and envb at the same time)

In this case, we will need a pure bytes version of os.get_exec_path(), and os._execvpe() should have a "bytes environment" mode (add an optional argument).

--

I have a patch fixing both problems, parts (a) and (b), but the patch depends on os.environb. I prefer to wait until os.environb is accepted to submit my patch.

----------
dependencies: +Create a bytes version of os.environ and getenvb() -Create fsencode() and fsdecode() functions in os.path

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

From report at bugs.python.org  Tue May  4 13:27:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 11:27:11 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272972431.5.0.0332896297075.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the fixes.  The latest patch looks good to me.

Alexander, is it okay for me to commit this?

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

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

From report at bugs.python.org  Tue May  4 13:58:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 11:58:58 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>


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

On POSIX (but not on Mac OS X), Python3 calls get_codeset() to get the file system encoding. If this function fails, sys.getfilesystemencoding() returns None.  PyUnicode_DecodeFSDefaultAndSize() fallbacks to utf-8 whereas subprocess fail:

  ...
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 670, in __init__
    restore_signals, start_new_session)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1101, in _execute_child
    executable_list = (fs_encode(executable),)
  File "/home/SHARE/SVN/py3k/Lib/subprocess.py", line 1088, in fs_encode
    return s.encode(fs_encoding, 'surrogateescape')
TypeError: encode() argument 1 must be string, not None

We have two choices: raise a fatal error if get_codeset() failed, or fallback to utf-8.

On Windows and Mac OS X, get_codeset() shouldn't be called because the result is just dropped. We should call _PyCodec_Lookup(Py_FileSystemDefaultEncoding) instead to ensure that the file system encoding can be loaded.

----------
components: Interpreter Core, Unicode
messages: 104924
nosy: haypo
priority: normal
severity: normal
status: open
title: Python3/POSIX:  errors if file system encoding is None
versions: Python 3.2

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

From report at bugs.python.org  Tue May  4 14:06:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 12:06:34 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272974794.39.0.660494758519.issue8557@psf.upfronthosting.co.za>


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

Fair enough.  Thank you for your detective work, and hopefully someone will be interested enough to pick this up again later.

----------
status: open -> languishing

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

From report at bugs.python.org  Tue May  4 14:12:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 12:12:50 +0000
Subject: [issue8608] fix_import prefixes "." to already relative imports
In-Reply-To: <1272963487.39.0.595362588306.issue8608@psf.upfronthosting.co.za>
Message-ID: <1272975170.95.0.494579092692.issue8608@psf.upfronthosting.co.za>


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

Thanks, but this is a duplicate of issue 8553, which has already been fixed.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> 2to3 breaks relative imports

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

From report at bugs.python.org  Tue May  4 14:17:58 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Tue, 04 May 2010 12:17:58 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1272975478.47.0.550869653118.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

Can anyone move this to Stage: patch review (for the fix approach proposed in msg90336)?  Or does anyone have better idea on how to move this closer to final fix or wontfix / reject?  Thank you!

----------

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

From report at bugs.python.org  Tue May  4 14:30:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 12:30:46 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272972431.5.0.0332896297075.issue1533@psf.upfronthosting.co.za>
Message-ID: <BEE4D0BB-FFBD-46BC-9B78-F6C0F236981F@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On May 4, 2010, at 7:27 AM, Mark Dickinson <report at bugs.python.org>  
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Thanks for the fixes.  The latest patch looks good to me.
>
> Alexander, is it okay for me to commit this?
>

Sure. Why do you have to ask?

----------
nosy: +Alexander.Belopolsky

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

From report at bugs.python.org  Tue May  4 14:34:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 12:34:04 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272976444.89.0.608433964524.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hi Alexander,

I took the liberty of messing with your patch slightly;  I didn't want to ask you to make further changes since the patch was fine, and my messing was mostly just to satisfy my own fussiness (only the first two items were really necessary):

Minor updates:
 - add Misc/NEWS entry
 - remove trailing whitespace and fix spaces that should have been a tab
 - added some extra tests to check all possible combinations of bad
   arguments, purely to check for refcounting problems
 - initialize low to NULL, to match the Py_XDECREF(low) (could change
   that Py_XDECREF to Py_DECREF instead, but the code's more resistant
   to random refactorings this way --- see next item :)
 - randomly refactor:  regroup blocks for ease of reading
 - don't do PyLong_FromLong(1) until it's needed ('zero' is different,
   since it's always used in the non-error case)
 - [micro-optimization]: don't pass a known zero value to
   get_range_long_argument

Any objections or comments?  Can I apply this version of the patch?

----------
Added file: http://bugs.python.org/file17200/issue1533_metd.diff

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

From report at bugs.python.org  Tue May  4 14:41:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 12:41:28 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272976444.89.0.608433964524.issue1533@psf.upfronthosting.co.za>
Message-ID: <3F29EB94-2602-4D17-B218-A041980D2CE6@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I see. Let me take a look.

BTW, I tried to use tabs for indentation in the patch, but emacs was  
not always happy about it. Is there some c-mode setting that I don't  
know about that would take care of that?

On May 4, 2010, at 8:34 AM, Mark Dickinson <report at bugs.python.org>  
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Hi Alexander,
>
> I took the liberty of messing with your patch slightly;  I didn't  
> want to ask you to make further changes since the patch was fine,  
> and my messing was mostly just to satisfy my own fussiness (only the  
> first two items were really necessary):
>
> Minor updates:
> - add Misc/NEWS entry
> - remove trailing whitespace and fix spaces that should have been a  
> tab
> - added some extra tests to check all possible combinations of bad
>   arguments, purely to check for refcounting problems
> - initialize low to NULL, to match the Py_XDECREF(low) (could change
>   that Py_XDECREF to Py_DECREF instead, but the code's more resistant
>   to random refactorings this way --- see next item :)
> - randomly refactor:  regroup blocks for ease of reading
> - don't do PyLong_FromLong(1) until it's needed ('zero' is different,
>   since it's always used in the non-error case)
> - [micro-optimization]: don't pass a known zero value to
>   get_range_long_argument
>
> Any objections or comments?  Can I apply this version of the patch?
>
> ----------
> Added file: http://bugs.python.org/file17200/issue1533_metd.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1533>
> _______________________________________

----------

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

From report at bugs.python.org  Tue May  4 14:43:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 12:43:49 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272977029.01.0.737876782184.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re emacs:

C-c . python

should set a python 2.x-friendly indentation mode.

There's also a python-new style floating around somewhere on the web (not part of emacs as standard), suitable for the 4-space indent style that's supposed to be used for new code.

----------

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

From report at bugs.python.org  Tue May  4 15:30:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 13:30:50 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>


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

Python3 is unable to start (bootstrap failure) on a POSIX system if the locale encoding is different than utf8 and the Python path (standard library path where the encoding module is stored) contains a non-ASCII character. (Windows and Mac OS X are not affected by this issue because the file system encoding is hardcoded.)

 - Py_FileSystemDefaultEncoding == NULL
 - calculate_path(): sys.path is filled with directory names decoded with the locale encoding
 - find_module() encodes each path using PyUnicode_AsEncodedString(..., Py_FileSystemDefaultEncoding, NULL): use "utf-8" encoding because Py_FileSystemDefaultEncoding is NULL

=> error because the path is not encoded and decoded with the same encoding

We cannot encodes a path with the locale encoding because we need find_module() to load the encoding codec, and loading the codec needs find_module()... (bootstrap error :-))

We should decodes the path using a fixed encoding (eg. ASCII or utf-8), use the same encoding to encodes paths in find_module(), and then reencode paths of all objects storing filenames:

 - sys.path list items
 - sys.modules dict keys
 - sys.modules values: each module have __file__ and/or __path__ attributes
 - all code objects (co_filename)
 - (maybe some other?)

The error occurs in an early stage of Py_InitializeEx(), so the object list is limited and we control this list (eg. site is not loaded yet).

Related issues:
 - #8610: "Python3/POSIX:  errors if file system encoding is None"
 - #8242: "Improve support of PEP 383 (surrogates) in Python3: meta-issue"

----------
components: Interpreter Core, Unicode
messages: 104932
nosy: haypo
priority: normal
severity: normal
status: open
title: Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)
versions: Python 3.2

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

From report at bugs.python.org  Tue May  4 15:32:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 13:32:12 +0000
Subject: [issue8242] Improve support of PEP 383 (surrogates) in Python3:
	meta-issue
In-Reply-To: <1269652357.44.0.254995855854.issue8242@psf.upfronthosting.co.za>
Message-ID: <1272979932.76.0.446402892042.issue8242@psf.upfronthosting.co.za>


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

I opened a different issue to use surrogates in Python module path: #8611, but the issue is not specific to surrogates ("Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)").

----------

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

From report at bugs.python.org  Tue May  4 15:36:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 13:36:47 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1272980207.06.0.363271809105.issue8611@psf.upfronthosting.co.za>


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

We could have a separate list storing the original bytes form of sys.path; this list would be used by find_module() as long as Py_FileSystemDefaultEncoding isn't initialized.

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

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

From report at bugs.python.org  Tue May  4 15:39:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 13:39:42 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1272980382.71.0.819302086752.issue8611@psf.upfronthosting.co.za>


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

Or find_module() could use wcstombs() as long as Py_FileSystemDefaultEncoding is NULL.

----------

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

From report at bugs.python.org  Tue May  4 15:57:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 13:57:46 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1272981466.2.0.957518744687.issue8477@psf.upfronthosting.co.za>


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

Most of this should be solved if the patch in issue8550 gets accepted. As for test_decode_certificate, it seems it isn't used anywhere, and could therefore be deleted.

----------

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

From report at bugs.python.org  Tue May  4 15:58:52 2010
From: report at bugs.python.org (Gunnlaugur Thor Briem)
Date: Tue, 04 May 2010 13:58:52 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1272981532.18.0.496469247588.issue8313@psf.upfronthosting.co.za>


Gunnlaugur Thor Briem <gunnlaugur at gmail.com> added the comment:

Replacing the message with its repr seems to me at least strongly preferable to the current ?hide it all? behavior. :)

Better, msg.encode('ascii', 'backslashreplace') does what repr does with unencodable characters, but does not add the quotes, so the behavior is only different when it needs to be.

Better still, 'ascii' need not be hardcoded. I'm attaching a patch that sets the encoding from an environment variable, defaulting to 'ascii', and encodes the message with 'backslashreplace'. This makes unicode string equality assertions much more useful for me.

The encoding could also be configurable by some clean hook for test runners to use. unit2 could have a command-line parameter, and TextTestRunner could use stream.encoding if not None (or PYTHONIOENCODING on Python 3).

Ideally messages should not be forced to be 8-bit strings by the failure exception class, but I suppose that's a bigger change than you would want to make.

The downside of using backslashreplace (or repr, for that matter) is that it does not preserve lengths, so the diff markers can get misaligned. I find that an acceptable tradeoff, but 'replace' is another option that preserves lengths, at least more often.

----------
keywords: +patch
nosy: +gthb
Added file: http://bugs.python.org/file17201/unittest2-issue-8313.patch

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

From report at bugs.python.org  Tue May  4 16:07:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 14:07:47 +0000
Subject: [issue3823] ssl.wrap_socket() is incompatible with servers that drop
	privileges, due to keyfile requirement
In-Reply-To: <1220984719.3.0.228126117566.issue3823@psf.upfronthosting.co.za>
Message-ID: <1272982067.38.0.825624874333.issue3823@psf.upfronthosting.co.za>


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

There's a patch in issue8550 to expose SSL contexts as first-class objects. It allows you to create first your context object(s) and load certificates, then drop privileges, then create sockets using this/these contexts.
In any case, resolution can't happen before 3.2. 2.7 is in feature freeze now.

----------
nosy: +pitrou
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Tue May  4 16:09:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 14:09:49 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1272975478.47.0.550869653118.issue5753@psf.upfronthosting.co.za>
Message-ID: <1272982331.3554.1.camel@localhost.localdomain>


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

> Can anyone move this to Stage: patch review (for the fix approach
> proposed in msg90336)?  Or does anyone have better idea on how to move
> this closer to final fix or wontfix / reject?  Thank you!

I stand by my opinion that adding another hack in the initialization
path will not do us a lot of good, while a separate API would solve the
problem neatly. Perhaps Dave Malcolm can chime in?

----------

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

From report at bugs.python.org  Tue May  4 16:10:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 May 2010 14:10:50 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1272982250.39.0.21765179993.issue8313@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sounds like a good solution - I'll look at this, thanks.

----------

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

From report at bugs.python.org  Tue May  4 16:16:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 14:16:15 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1272982575.97.0.493788788106.issue8611@psf.upfronthosting.co.za>


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

I have a patch implementation most of the point described in my first message. I have to rework on it before submit it. The patch depends on other issues, and I prefer to first fix all related issues.

----------

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

From report at bugs.python.org  Tue May  4 16:17:15 2010
From: report at bugs.python.org (Zaar Hai)
Date: Tue, 04 May 2010 14:17:15 +0000
Subject: [issue8612] multiprocessing Queue module failes to send INIConfig
	objects
In-Reply-To: <1272982635.61.0.958839100699.issue8612@psf.upfronthosting.co.za>
Message-ID: <1272982635.61.0.958839100699.issue8612@psf.upfronthosting.co.za>


New submission from Zaar Hai <haizaar at gmail.com>:

I'm using INIConfig class from iniparse module(http://code.google.com/p/iniparse).
I've tried to use multiprocessing.Queue to propagate 
configuration changes between the processes. However, INIConfig instances 
have troubles being pushed through Queue objects.

I do not know whether this is a Queue or iniparse bug, so I've opened issued on both projects(http://code.google.com/p/iniparse/issues/detail?id=20). Even this is not a Queue bug, it would be great to have some advice on how this problem may be solved. Thanks.

Problem description:

Running this simple code:

from multiprocessing import Process
from multiprocessing import Queue
from iniparse import INIConfig
import time

def worker(queue):
    config = queue.get()
    print config.sec1.var1

def main():
    config = INIConfig(open("./my.conf"))
    queue = Queue()
    p = Process(target=worker, args=(queue,))
    p.start()
    queue.put(config)
    time.sleep(1)

if __name__ == "__main__":
    main()

Raised this error:
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.5/multiprocessing/queues.py", line 242, in _feed
    send(obj)
TypeError: 'Undefined' object is not callable

The contents of my.conf are like this:
[sec1]
var1 = test1
var2 = test2

I'm using python 2.5.2 on Debian Lenny amd64 with python-multiprocessing package (http://packages.debian.org/squeeze/python-multiprocessing).

----------
components: None
messages: 104942
nosy: Zaar.Hai
priority: normal
severity: normal
status: open
title: multiprocessing Queue module failes to send INIConfig objects
versions: Python 2.5

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

From report at bugs.python.org  Tue May  4 16:31:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 May 2010 14:31:04 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1272983464.6.0.773397987753.issue8313@psf.upfronthosting.co.za>


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

Very recently, issue8533 changed regrtest.py to use 'backslashreplace' when printing errors. This issue seems very similar

----------
nosy: +amaury.forgeotdarc, haypo

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

From report at bugs.python.org  Tue May  4 16:39:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 14:39:08 +0000
Subject: [issue8567] decimal module doesn't respect precedence rules for
	exceptional conditions
In-Reply-To: <1272539429.01.0.227079774341.issue8567@psf.upfronthosting.co.za>
Message-ID: <1272983948.56.0.691743217555.issue8567@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Precedence fixed in r80753 through r80756.

That still leaves open the problem of what flags should be set;  however, we should discuss this in a separate issue.

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

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

From report at bugs.python.org  Tue May  4 16:54:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 14:54:01 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>


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

In an effort to keep to one issue per tracker item, I'm pulling this issue out of the comments on issue 8567.

Issue:  if a Decimal operation raises several signals, and one or more of those signals is trapped, how should that operation affect flags?

Decimal currently ends up setting some or none of those flags, depending on exactly which signal is trapped first.

Stefan points out that cdecimal and decnumber both treat all operations as atomic:  *all* flags relevant to that operation are set, and only then are any traps acted on.

The specification isn't clear on this.  At http://speleotrove.com/decimal/daexcep.html it says:

"""The value of the trap-enabler for each signal in the context determines whether an operation is completed after the condition is detected or whether the condition is trapped and hence not necessarily completed (see IEEE 754 ?7 and ?8)."""

There's also this (thanks, Stefan), in http://speleotrove.com/decimal/damodel.html

"""For each of the signals, the corresponding flag is set to 1 when the signal occurs. It is only reset to 0 by explicit user action."""

However, this doesn't really help: do we regard signals as being raised one-by-one during (or at the end of) an operation, or all at once?  And should a trap take effect the moment a signal is handled, or should all traps be delayed until the end of an operation?

----------
assignee: mark.dickinson
messages: 104945
nosy: facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
stage: unit test needed
status: open
title: Decimal module flags undetermined when a signal is trapped.
type: behavior

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

From report at bugs.python.org  Tue May  4 17:01:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 15:01:49 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1272985309.89.0.394371678032.issue8313@psf.upfronthosting.co.za>


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

The example raises an AssertionError(u'\n- \ufffd+ \ufffd\ufffd') which is converted to string by traceback.format_exception(). This function fails in _some_str() on str(value) instruction. You can reproduce the error with:

>>> str(AssertionError(u"\xe9"))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128)

> The problem with creating unicode tracebacks is that they could 
> fail when being output on terminals not capable of showing 
> the full range of unicode characters (the default terminal 
> on Windows is CP1252).

The problem is not related to the terminal encoding: str(value) uses Python default encoding (ASCII by default). Python3 is not concerned because str(AssertionError("\xe9")) doesn't raise any error: it returns "\xe9".

----------
components: +Unicode
versions:  -Python 3.2

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

From report at bugs.python.org  Tue May  4 17:04:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 15:04:10 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1272985450.51.0.861229087364.issue8313@psf.upfronthosting.co.za>


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

> Very recently, issue8533 changed regrtest.py to use
> 'backslashreplace' when printing errors. This issue seems 
> very similar

Issue #8533 is not directly related because in this issue the error occurs before writing the traceback to the terminal.

----------

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

From report at bugs.python.org  Tue May  4 17:11:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 15:11:19 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272985879.73.0.568471836882.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 4, 2010 at 8:34 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> I took the liberty of messing with your patch slightly;  I didn't want
> to ask you to make further changes since the patch was fine, and my
> messing was mostly just to satisfy my own fussiness (only the first
> two items were really necessary):
>

Thank you for doing it.  The patch is good to go, questions and comments below are just for my education.

> Minor updates:
>  - add Misc/NEWS entry

What is the standard practice on this?  I thought Misc/NEWS entry was similar to commit message and would be written by a committer.  What are the guidelines for writing such entries?  I see that some entries simply repeat the title of the issues while others got into greater details.

>  - remove trailing whitespace and fix spaces that should have been
> a tab

I've looked at my patch through cat -et and couldn't find any tab/space issues.  I did notice one empty line with a single space that you removed.  Do you use an automated checking tool for this?  I just did grep " $".  BTW, the current trunk version (r80752) of Python/bltinmodule.c has two lines with trailing white space:

$ cat -n Python/bltinmodule.c | grep " $" | cat -et
   641^I^I^IPyErr_SetString(PyExc_TypeError, $
  2966^I        $


>  - added some extra tests to check all possible combinations of bad
>   arguments, purely to check for refcounting problems

With arguments processing segregated in a common function, I am not sure  whether additional tests actually increase coverage.  This brings a question: what is the recommended way to produce coverage statistics for  C modules?  regrtest.py --coverage seems to be for python modules only. 

>  - initialize low to NULL, to match the Py_XDECREF(low) (could change
>   that Py_XDECREF to Py_DECREF instead, but the code's more resistant
>   to random refactorings this way --- see next item :)

Good catch.  Wouldn't the same argument apply to ilow?  Wouldn't static code checkers complain about redundant initialization?

>  - randomly refactor:  regroup blocks for ease of reading

I actually disagree that your regrouping makes the code clearer.  In my version, all idiosyncratic argument processing is done with borrowed references first followed by common processing in three similar blocks.  This, however, is purely matter of taste.  Note that I considered changing i* names to raw* names, but decided not to introduce more changes than necessary.  In your grouping, however, the similarity of variable names is more of an issue.  This said, I don't really have any problem with your choice.

>  - don't do PyLong_FromLong(1) until it's needed ('zero' is different,
>   since it's always used in the non-error case)

Yes, I considered that. A further micro-optimization would be to initialize a static variable in module initialization and reuse it in get_len_of_range_longs as well.  I decided to put it next to zero instead to simplify the logic.

>  - [micro-optimization]: don't pass a known zero value to
>   get_range_long_argument

Is it really worth it?  Default start is probably not that common in case of long arguments.


> Any objections or comments?  Can I apply this version of the patch?
>

The above are not objections.  Please apply this version of the patch.

----------

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

From report at bugs.python.org  Tue May  4 17:12:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 15:12:11 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272985931.3.0.737862722305.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: belopolsky -> mark.dickinson

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

From report at bugs.python.org  Tue May  4 17:17:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 15:17:07 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1272986227.27.0.200775794134.issue8313@psf.upfronthosting.co.za>


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

Attached patch fixes _some_str() function of the traceback module: encode unicode exception message to ASCII using backslashreplace error handler. ASCII is not the best choice, but str(unicode(...)) uses also ASCII (the default encoding) and we don't know the terminal encoding in traceback. We cannot do better here in Python2 (without breaking a lot of APIs...).

The right fix is to use Python3 which formats a traceback to unicode (unicode characters of the error message are kept unchanged). The choice of the encoding and error handler is made only at the end, when writing the output to the terminal, which is the right thing to do.

----------
Added file: http://bugs.python.org/file17202/traceback_unicode.patch

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

From report at bugs.python.org  Tue May  4 17:25:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 15:25:37 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1272986737.71.0.531056947511.issue5753@psf.upfronthosting.co.za>


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

FWIW I agree with Antoine.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue May  4 17:49:13 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 04 May 2010 15:49:13 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272988153.33.0.634426659091.issue8576@psf.upfronthosting.co.za>


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

> You mean that socket.create_connection(), httplib (issue 3972) and ftplib (issue 8594) should have used a different API to implement their "source_address" option?

I'm not sure what you mean.  The problem here is that you cannot reliably bind a specific local address because it might be bound already.

This is bad in unit tests because it causes spurious failures that waste developer effort forcing people to investigate non-bugs or because it causes people to ignore the results of the test suite.

This is bad in real applications because it prevents an application from working as it is supposed to.

Perhaps you have an application which requires that HTTP requests are issued from (1.2.3.4, 12345).  Then you'd better use an HTTP client library that lets you bind to this address when connecting to the HTTP server.  But the application is going to be prone to failure.  If you can't get around the requirement, then you just get to live with an unreliable application.

There's no such requirement in any unit test, though.  Unit tests can do whatever they want in order to achieve the goal of exercising the relevant implementation code and verify the results to be correct.  I don't think there are any unit tests which need to bind to one specific address in order to accomplish this goal.

----------

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

From report at bugs.python.org  Tue May  4 18:03:12 2010
From: report at bugs.python.org (Paul Moore)
Date: Tue, 04 May 2010 16:03:12 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272988992.29.0.0457285436132.issue8576@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

One of the tests in test_socket is checking that an attempt to connect to a port with no server running gives socket.error. For that, we need a port that's guaranteed to have no server present.

I think that one of the tests in test_httplib checks the source_address attribute to make sure the port it contains is the one you connected on - again, you need a specific port and it can't be in use. (Sorry, I'm not precise on the details of this one as it's only in trunk and I'm not at a PC with a trunk checkout at the moment).

Arguably these tests are of limited value and could simply be deleted, but they are there, and I don't see a way of implementing them without using something that gives you an unused port number...

----------

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

From report at bugs.python.org  Tue May  4 18:14:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 16:14:42 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272989682.27.0.0624640548133.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Some of the Alexander's questions about procedures aren't really related to this issue;  I've answered those offline.  Here are the answers to the others.]


>>  - initialize low to NULL, to match the Py_XDECREF(low) (could change
>>   that Py_XDECREF to Py_DECREF instead, but the code's more resistant
>>   to random refactorings this way --- see next item :)
>
> Good catch.  Wouldn't the same argument apply to ilow?  Wouldn't static code checkers complain about redundant initialization?

ilow doesn't need to be initialized because the PyArgs_ParseTuple is
guaranteed to either fail or initialize it, and I can't see that the
PyArgs_ParseTuple call is likely to change.  But I admit that the lack
of initialization here also makes me uncomfortable, especially in
combination with the assert that's there.  I might add an
initialization.

Do static code checkers really complain about redundant
initializations?  If anything, it seems like good defensive
programming practice to initialize variables, even
unnecessarily---later refactoring might make those initializations
necessary.

>
>>  - randomly refactor:  regroup blocks for ease of reading
>
> I actually disagree that your regrouping makes the code clearer.  In my version, all idiosyncratic argument processing is done with borrowed references first followed by common processing in three similar blocks.  This, however, is purely matter of taste.  Note that I considered changing i* names to raw* names, but decided not to introduce more changes than necessary.  In your grouping, however, the similarity of variable names is more of an issue.  This said, I don't really have any problem with your choice.

Okay, fair enough.  I agree it's a matter of taste.  I like the three
separate blocks, one for each argument, especially since the
refcounting semantics are clear:  each block adds exactly one
reference.  But each to his own. :)

>
>>  - don't do PyLong_FromLong(1) until it's needed ('zero' is different,
>>   since it's always used in the non-error case)
>
> Yes, I considered that. A further micro-optimization would be to initialize a static variable in module initialization and reuse it in get_len_of_range_longs as well.  I decided to put it next to zero instead to simplify the logic.

Hmm.  Possibly.  I have an unhealthy and probably irrational aversion
to non-constant static variables, even if the only time that the
variable is changed is at module initialization.

>
>>  - [micro-optimization]: don't pass a known zero value to
>>   get_range_long_argument
>
> Is it really worth it?  Default start is probably not that common in case of long arguments.

Yes, possibly not. :)  Partly I made this change because the
assignment 'ilow = zero;' again raises a red flag for me, because it's
not accompanied by a 'Py_INCREF(zero);' as I'd expect it to be.  I
realize that in this case it works out (because ilow is already a
borrowed reference, and we're replacing it with a borrowed reference
to zero), but it's sufficiently unusual that I have to think about it.
 This is personal preference again, I guess.

----------

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

From report at bugs.python.org  Tue May  4 18:18:19 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 04 May 2010 16:18:19 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272989899.13.0.384068886094.issue8576@psf.upfronthosting.co.za>


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

> One of the tests in test_socket is checking that an attempt to connect to a port with no server running gives socket.error. For that, we need a port that's guaranteed to have no server present.

A good way to do this is to create a socket, bind it to an address (any address - ie ('', 0)), ask it what its address is, and use that as the destination of the connect attempt.  Since you didn't listen() on it, it's not a server, and it won't accept any connections.

Doing it this way is again more reliable, since if you try to discover an unused address with find_unused_port, a real server might end up re-using that address by the time your test gets around to trying to connect to it.

> I think that one of the tests in test_httplib checks the source_address attribute to make sure the port it contains is the one you connected on - again, you need a specific port and it can't be in use.

If you're talking about SourceAddressTest.testHTTPConnectionSourceAddress, I see what you mean.  This is basically an integration test between httplib and the socket module.  No actual socket is required here.  I would implement this test using a fake socket object.  This would allow the test assertion to be strengthened (it currently doesn't assert anything about the ip part of the address, it only checks the port), and still avoids running into problems binding a *real* local address.

> Arguably these tests are of limited value and could simply be deleted

I definitely would not argue this.  These tests seem to cover real functionality which isn't directly covered elsewhere.  They shouldn't be deleted, but fixed to avoid the potential races they're subject to now.

----------

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

From report at bugs.python.org  Tue May  4 18:30:49 2010
From: report at bugs.python.org (Paul Moore)
Date: Tue, 04 May 2010 16:30:49 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
	on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1272990649.17.0.97063638821.issue8576@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Thanks for the suggestions, I'll see if I can implement something based on them.

----------

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

From report at bugs.python.org  Tue May  4 18:32:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 16:32:55 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272990775.47.0.589723735502.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied to trunk in r80758.

Do people want this to go into 2.6 as well?  The patch would need to be modified to produce a warning for floats instead of giving a TypeError (and the tests would need to be modified to test for that warning).

----------

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

From report at bugs.python.org  Tue May  4 18:36:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 16:36:46 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1272990775.47.0.589723735502.issue1533@psf.upfronthosting.co.za>
Message-ID: <g2qd38f5331005040936jcc552fc0xe9a51d91f78010fd@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, May 4, 2010 at 12:32 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Applied to trunk in r80758.
>
> Do people want this to go into 2.6 as well?

Also, should additional unit tests forward ported to 3.x?  If so, let
me do it as an exercise in creating a ready to commit patch. :-)

----------

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

From report at bugs.python.org  Tue May  4 18:40:31 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 04 May 2010 16:40:31 +0000
Subject: [issue8008] Allow Arbitrary OpenID providers in this bug tracker
In-Reply-To: <1266975080.64.0.184053861131.issue8008@psf.upfronthosting.co.za>
Message-ID: <1272991231.8.0.869314720327.issue8008@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Someway, the closed state vanished.

----------
nosy:  -georg.brandl, r.david.murray
priority: normal -> 

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

From report at bugs.python.org  Tue May  4 18:41:22 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 04 May 2010 16:41:22 +0000
Subject: [issue8008] Allow Arbitrary OpenID providers in this bug tracker
In-Reply-To: <1266975080.64.0.184053861131.issue8008@psf.upfronthosting.co.za>
Message-ID: <1272991282.24.0.205467916381.issue8008@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Uhmmm... My browser seems crazy.

----------
nosy: +georg.brandl, r.david.murray

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

From report at bugs.python.org  Tue May  4 18:43:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 16:43:19 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272991399.28.0.907537770565.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 for forward-porting/adapting relevant tests to py3k.

----------
assignee: mark.dickinson -> belopolsky

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

From report at bugs.python.org  Tue May  4 19:59:33 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 May 2010 17:59:33 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272995973.23.0.0616501637708.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Any idea where this path comes from? I can go spelunking through the code myself to investigate.

----------

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

From report at bugs.python.org  Tue May  4 20:00:56 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 May 2010 18:00:56 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1272996056.68.0.323908580871.issue8611@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue May  4 20:10:44 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 May 2010 18:10:44 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272996644.66.0.325594572144.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Ok, so the cause of the bug is 'simple' - not sure what the best fix is.

When I run python from a freshly built py3k I have the following as sys.path:

['', '/dev/null/lib/python32.zip', '/compile/python-trunk3/Lib', '/compile/python-trunk3/Lib/plat-darwin', '/compile/python-trunk3/build/lib.macosx-10.4-x86_64-3.2-pydebug', '/Volumes/Second Drive/michael/.local/lib/python/3.2/site-packages']

Note that weird second entry!

support.forget(...) trys to unlink the supplied name (+.py + c|o) from every path in sys.path.

The unlink function catches OSError, but *only* if the errno is errno.ENOENT. On my system the specific error raises is:

OSError: [Errno 20] Not a directory

----------

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

From report at bugs.python.org  Tue May  4 20:12:15 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 May 2010 18:12:15 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272996735.13.0.62782108163.issue8586@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Maybe you just want to relax the test in the except clause of test.support.unlink()?  Or change the test to

if error.errno not in (errno.ENOENT, errno.ENOTDIR)

?

----------

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

From report at bugs.python.org  Tue May  4 20:14:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 May 2010 18:14:50 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272996890.96.0.655640530824.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

On trunk the definition of unlink is:


def unlink(filename):
    try:
        os.unlink(filename)
    except OSError:
        pass

:-)

Changing it as you suggest fixes the problem though. Ok to commit?

----------

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

From report at bugs.python.org  Tue May  4 20:18:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 18:18:05 +0000
Subject: [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>


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

test_buffered_reader test_gzip is failing for me since r80720, on trunk on OS X 10.6.3:

======================================================================
ERROR: test_buffered_reader (__main__.TestGzip)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_gzip.py", line 91, in test_buffered_reader
    lines = [line for line in r]
  File "/Users/dickinsm/python/svn/trunk/Lib/gzip.py", line 365, in flush
    self.fileobj.flush()
IOError: [Errno 9] Bad file descriptor

----------------------------------------------------------------------
Ran 16 tests in 1.258s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_gzip.py", line 271, in <module>
    test_main(verbose=True)
  File "Lib/test/test_gzip.py", line 268, in test_main
    test_support.run_unittest(TestGzip)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 1038, in run_unittest
    _run_suite(suite)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 1021, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_gzip.py", line 91, in test_buffered_reader
    lines = [line for line in r]
  File "/Users/dickinsm/python/svn/trunk/Lib/gzip.py", line 365, in flush
    self.fileobj.flush()
IOError: [Errno 9] Bad file descriptor


Here's a minimal Python script that produces the failure:

import gzip
import io

f = gzip.GzipFile('hamster', 'wb')
f.write("some data")
f.close()

f = gzip.GzipFile('hamster', 'rb')
r = io.BufferedReader(f)
lines = [line for line in r]
r.close()

This gives the following output:

Traceback (most recent call last):
  File "test_gzip.py", line 11, in <module>
    r.close()
  File "/Users/dickinsm/python/svn/trunk/Lib/gzip.py", line 365, in flush
    self.fileobj.flush()
IOError: [Errno 9] Bad file descriptor
[20213 refs]

----------
components: Library (Lib)
messages: 104965
nosy: mark.dickinson, pitrou
priority: normal
severity: normal
status: open
title: test_gzip fails on OS X
versions: Python 2.7

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

From report at bugs.python.org  Tue May  4 20:19:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 18:19:19 +0000
Subject: [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272997159.69.0.96052318118.issue8614@psf.upfronthosting.co.za>


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

Can you try the following:

>>> f = open('LICENSE', 'rb')
>>> f.flush()

----------

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

From report at bugs.python.org  Tue May  4 20:22:09 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 04 May 2010 18:22:09 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1272997329.98.0.916690332329.issue8586@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

+1

----------
assignee: barry -> michael.foord
resolution: works for me -> accepted

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

From report at bugs.python.org  Tue May  4 20:28:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 18:28:17 +0000
Subject: [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272997697.98.0.702407452878.issue8614@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yep, that's enough to trigger it:

Python 2.7b1+ (trunk:80760, May  4 2010, 19:27:27) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('LICENSE', 'rb')
[35032 refs]
>>> f.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
[35067 refs]

----------

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

From report at bugs.python.org  Tue May  4 20:29:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 May 2010 18:29:46 +0000
Subject: [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272997786.15.0.0727393521328.issue8614@psf.upfronthosting.co.za>


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

Ok, can you try the following patch then:

Index: Lib/gzip.py
===================================================================
--- Lib/gzip.py	(r?vision 80760)
+++ Lib/gzip.py	(copie de travail)
@@ -362,7 +362,7 @@
         if self.mode == WRITE:
             # Ensure the compressor's buffer is flushed
             self.fileobj.write(self.compress.flush(zlib_mode))
-        self.fileobj.flush()
+            self.fileobj.flush()
 
     def fileno(self):
         """Invoke the underlying file object's fileno() method.

----------

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

From report at bugs.python.org  Tue May  4 20:30:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 18:30:18 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1272997818.78.0.377096469151.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a py3k patch that adds new tests.  Since there are no end user visible changes, I don't believe a Misc/NEWS entry is needed.  A commit message may read:

Issue #1533: Tests only. Added tests for consistency in range function argument processing. 

Note that the first chunk:

-        # Reject floats when it would require PyLongs to represent.
-        # (smaller floats still accepted, but deprecated)
+        # Reject floats.
+        self.assertRaises(TypeError, range, 1., 1., 1.)

is applicable to the trunk as well.

----------
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17203/issue1533-py3k-tests.diff

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

From report at bugs.python.org  Tue May  4 20:30:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 18:30:53 +0000
Subject: [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272997853.5.0.808167701458.issue8614@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That fixes the failure.

----------

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

From report at bugs.python.org  Tue May  4 20:39:43 2010
From: report at bugs.python.org (Sriram)
Date: Tue, 04 May 2010 18:39:43 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1272998383.83.0.0859369444174.issue5727@psf.upfronthosting.co.za>


Sriram <sriramrathinavelu at yahoo.com> added the comment:

Hi,

On second thoughts, it made more sense to validate pdb directly instead of validating doctest's debugger.

I have also used few inputs, I got from irc chat at #python-dev room in writing the test case. Thanks to them.

I have attached the svn diff.

Please review them

Thanks
Sriram

----------
Added file: http://bugs.python.org/file17204/pdb_doctest_readline.patch

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

From report at bugs.python.org  Tue May  4 20:49:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 May 2010 18:49:17 +0000
Subject: [issue8614] test_gzip fails on OS X
In-Reply-To: <1272997084.97.0.485599300068.issue8614@psf.upfronthosting.co.za>
Message-ID: <1272998957.75.0.536488032265.issue8614@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Antoine.  Applied in r80762 through r80765.

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

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

From report at bugs.python.org  Tue May  4 20:52:52 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 04 May 2010 18:52:52 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1272999172.58.0.983331970964.issue5727@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  4 20:58:05 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 04 May 2010 18:58:05 +0000
Subject: [issue8483] asyncore.dispatcher's __getattr__ method produces
	confusing effects
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1272999485.16.0.343876249792.issue8483@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

As per discussion on #python-dev we think it's better to proceed as follows:

for python 2.7 and 3.2: 
 - fix __getattr__ error message
 - raise a DeprecationWarning if cheap inheritance is used and definitively remove its support in the next major version
 - create an alias for __str__

For Python 2.6 and 3.1: just fix __getattr__ error message.

Patch for Python 2.7 is in attachment.

----------
assignee:  -> giampaolo.rodola
stage:  -> commit review
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17205/2.7.patch

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

From report at bugs.python.org  Tue May  4 21:19:56 2010
From: report at bugs.python.org (cburroughs)
Date: Tue, 04 May 2010 19:19:56 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1273000796.56.0.0946155473824.issue812369@psf.upfronthosting.co.za>


Changes by cburroughs <chris.burroughs at gmail.com>:


----------
nosy: +cburroughs

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

From report at bugs.python.org  Tue May  4 21:20:14 2010
From: report at bugs.python.org (cburroughs)
Date: Tue, 04 May 2010 19:20:14 +0000
Subject: [issue7835] Minor bug in 2.6.4 related to cleanup at end of program
Message-ID: <1273000814.02.0.636058493531.issue7835@psf.upfronthosting.co.za>


Changes by cburroughs <chris.burroughs at gmail.com>:


----------
nosy: +cburroughs

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

From report at bugs.python.org  Tue May  4 22:39:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 May 2010 20:39:39 +0000
Subject: [issue5727] doctest pdb readline broken
In-Reply-To: <1239276305.19.0.526867750163.issue5727@psf.upfronthosting.co.za>
Message-ID: <1273005579.15.0.573119192132.issue5727@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue May  4 23:15:01 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:15:01 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

The file submitted, turtle.py, essentially contains a backport of the new features, which were added to the turtle module with Python 3.1.
Otherwise this versions is 100% compatible with the turtle module of Python 2.6. 
So scripts written with Python 3.1's turtle module will run unchanged with identical behaviour under Python 2.7. The same do - of course - scripts written with Python 2.6's version of the turtle module.

Remark: There were also some enhancements and cleanup in the code for Python 3.1, which I also did backport to this version. 

Inclusion of this version of turtle.py into Python 2.7 will need an update of the docs (essentially to those of Python 3.1). I'll be able to submit an appropriate *.rst file within a week or so.

----------
components: Library (Lib)
files: turtle.py
messages: 104975
nosy: georg.brandl, gregorlingl, loewis
priority: normal
severity: normal
status: open
title: turtle.py - backport of 3.1 features
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17206/turtle.py

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

From report at bugs.python.org  Tue May  4 23:21:22 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:21:22 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273008082.99.0.60191390665.issue8615@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Here, just for your information, the appropriate unified diff (from the version in 2.7b1 to the new submitted one.

----------
keywords: +patch
Added file: http://bugs.python.org/file17207/turtle27b1_to_turtle27.diff

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

From report at bugs.python.org  Tue May  4 23:30:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 04 May 2010 21:30:18 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273008618.78.0.322840671016.issue8615@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


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

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

From report at bugs.python.org  Tue May  4 23:32:10 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:32:10 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

turtleDemo.py contains a string referring to the outdated xturtle.
Should be replaced according to the submitted diff.

Moreover I'd like to propose to add to demo-scripts to the Demo-directory, namely tdemo_nim.py and tdemo_round_dance.py as well as to replace the old tdemo_paint.py by the enhanced version tdemo_scribble.py. I'll add those files subsequently.
Regards,
Gregor

----------
components: Demos and Tools
files: turtleDemo_27b1_to_turtleDemo.diff
keywords: patch
messages: 104977
nosy: georg.brandl, gregorlingl, loewis
priority: normal
severity: normal
status: open
title: Changes to content of Demo/turtle
versions: Python 2.7
Added file: http://bugs.python.org/file17208/turtleDemo_27b1_to_turtleDemo.diff

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

From report at bugs.python.org  Tue May  4 23:33:05 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:33:05 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1273008785.15.0.98768968924.issue8616@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Added file: http://bugs.python.org/file17209/tdemo_nim.py

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

From report at bugs.python.org  Tue May  4 23:33:28 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:33:28 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1273008808.27.0.650213310499.issue8616@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Added file: http://bugs.python.org/file17210/tdemo_round_dance.py

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

From report at bugs.python.org  Tue May  4 23:33:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 May 2010 21:33:47 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273008827.84.0.206230919117.issue8615@psf.upfronthosting.co.za>


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

Unfortunately, I feel that you are (again) too late here. 2.7 has already seen its first beta release, so new features are not acceptable. You can still try to petition acceptance of new features with the release manager.

----------

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

From report at bugs.python.org  Tue May  4 23:34:28 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 21:34:28 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1273008868.04.0.456550333488.issue8616@psf.upfronthosting.co.za>


Changes by Gregor Lingl <gregorlingl at users.sourceforge.net>:


Added file: http://bugs.python.org/file17211/tdemo_scribble.py

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

From report at bugs.python.org  Wed May  5 00:06:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 May 2010 22:06:50 +0000
Subject: [issue8432] buildbot: test_send_signal of test_subprocess failure
In-Reply-To: <1271522195.0.0.944847217112.issue8432@psf.upfronthosting.co.za>
Message-ID: <1273010810.15.0.18035959541.issue8432@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I get this same failure on Mac OS X 10.6.3 as well.

----------
nosy: +michael.foord

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

From report at bugs.python.org  Wed May  5 00:19:16 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 22:19:16 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273011556.49.0.779777282383.issue8615@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

As far as I remember, in the past there was a feature - freeze only with the appearance of beta2?

Maybe I'm wrong. So there remains only to try to interpret the term "new feature" appropriately, as all those features are already present in Python 3.1. If there are serious objections against adopting it, I'll accept them of course.

I just wanted to serve the community with making Python 2.7 more similar to Python 3.1

Regards,
Gregor

----------

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

From report at bugs.python.org  Wed May  5 00:37:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 May 2010 22:37:46 +0000
Subject: [issue8586] test_imp.py test failures on Py3K Mac OS X
In-Reply-To: <1272710295.84.0.106568163829.issue8586@psf.upfronthosting.co.za>
Message-ID: <1273012666.55.0.222804161404.issue8586@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 80771.

----------
assignee: michael.foord -> barry
resolution: accepted -> works for me
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed May  5 00:40:40 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 04 May 2010 22:40:40 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273012840.4.0.362891419024.issue8615@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

I see, that Benjamin Peterson, the release manager, is on the nosy list now. So please decide on this issue. If you need any supplementary information, I'll try to provide it.

(The issue concerning the adoption of this version of the turtle module for Python 3.1 can be found here: http://bugs.python.org/issue5923)

Regards,
Gregor

----------

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

From report at bugs.python.org  Wed May  5 00:42:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 04 May 2010 22:42:45 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1273012965.06.0.791568282114.issue8616@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


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

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

From report at bugs.python.org  Wed May  5 00:55:06 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 04 May 2010 22:55:06 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1273013706.95.0.449896740585.issue7472@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Adding unit-test for the patch

----------
keywords: +patch
Added file: http://bugs.python.org/file17212/test_email.patch

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

From report at bugs.python.org  Wed May  5 01:34:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 May 2010 23:34:27 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273016067.99.0.713871493039.issue8610@psf.upfronthosting.co.za>


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

Here is a patch for the first solution: display a fatal error if we are unable to get the locale encoding. It does always exit with a fatal error if nl_langinfo(CODESET) is not available (and Py_FileSystemDefaultEncoding is not set).

I don't think it's a good idea to display an fatal error at runtime. If nl_langinfo(CODESET) is not available, configure should fail or we should fallback to an hardcoded encoding (ok but which one?).

Extract of the nl_langinfo() manual page (on Linux):

CONFORMING TO
       SUSv2, POSIX.1-2001.

----------
keywords: +patch
Added file: http://bugs.python.org/file17213/no_fsencoding_error.patch

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

From report at bugs.python.org  Wed May  5 01:51:20 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 23:51:20 +0000
Subject: [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

http://docs.python.org/library/site.html#module-site mentions two variables that don't appear in my Python 2.6.5 installation's site module:

PYTHONNOUSERSITE
New in version 2.6.

PYTHONUSERBASE
New in version 2.6.

----------
assignee: docs at python
components: Documentation
messages: 104985
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: Non-existent variables documented
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 02:15:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:15:52 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273018552.76.0.742694587977.issue8610@psf.upfronthosting.co.za>


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

Patch for the second solution (fallback to utf-8 on get_codeset() failure):

 - create a subfunction initfsencoding() (Py_InitializeEx is already very long)
 - hardcode the encoding to utf-8 if nl_langinfo(CODESET) is missing
 - don't call get_codeset() on Windows or Mac OS X
 - call _PyCodec_Lookup(Py_FileSystemDefaultEncoding) if get_codeset() was not called (eg. on Windows) or if get_codeset() failed to ensure that the codec can be (and is) loaded: display a fatal error on failure

Since I wrote patches for both solution, I can now compare correctly advantages and disavantages. I prefer initfsencoding() because it works on all cases and is simpler than no_fsencoding_error.patch.

----------
Added file: http://bugs.python.org/file17214/initfsencoding.patch

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

From report at bugs.python.org  Wed May  5 02:20:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:20:01 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273018801.04.0.0525000713993.issue8603@psf.upfronthosting.co.za>


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

@loewis: So do you agree to add os.environb and os.getenvb()?

The documentation of os.environb and os.getenvb() in my last patch is very short. I'm not inspired.

We told me on IRC to not use function annotations because annotation semantic was not decided yet.

I will try to improve the documentation and remove the annotations in my next patch.

----------

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

From report at bugs.python.org  Wed May  5 02:20:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:20:18 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273018818.41.0.919058801313.issue8610@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


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

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

From report at bugs.python.org  Wed May  5 02:22:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 00:22:10 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273018930.33.0.748601749947.issue8610@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Wed May  5 02:23:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 05 May 2010 00:23:21 +0000
Subject: [issue8618] test_winsound failing on Windows Server 2008
In-Reply-To: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>
Message-ID: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>


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

Some of the test_alias_* functions in test_winsound are failing with a RuntimeError "Failed to play sound" when run on Server 2008 R2. 

The sound from each test exists in the registry so the test doesn't end up getting skipped. I'm guessing there is some missing privilege, so it's possible we should additionally skip based on that.

----------
assignee: brian.curtin
components: Tests, Windows
messages: 104988
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_winsound failing on Windows Server 2008
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/issue8618>
_______________________________________

From report at bugs.python.org  Wed May  5 02:30:54 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 05 May 2010 00:30:54 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273019454.96.0.418215831099.issue8610@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Wed May  5 02:32:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:32:24 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1273019544.11.0.438727249101.issue8313@psf.upfronthosting.co.za>


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

> The downside of using backslashreplace (or repr, for that matter) is
> that it does not preserve lengths, so the diff markers can get
> misaligned. I find that an acceptable tradeoff, but 'replace' is
> another option that preserves lengths, at least more often.

'replace' loose important informations: if the test is about the unicode string content, we will be unable to see the error data.

Result of the first example with my patch (backslashreplace):
======================================================================
FAIL: test_fffd (__main__.Foo)                                        
----------------------------------------------------------------------
Traceback (most recent call last):                                    
  File "x.py", line 3, in test_fffd                                   
    def test_fffd(self): self.assertEqual(u'\ufffd', u'\ufffd\ufffd') 
AssertionError:                                                       
- \ufffd+ \ufffd\ufffd                                                

Result of the first example with 'replace' error handler:
======================================================================
FAIL: test_fffd (__main__.Foo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "x.py", line 3, in test_fffd
    def test_fffd(self): self.assertEqual(u'\ufffd', u'\ufffd\ufffd')
AssertionError:
- ?+ ??

(but this example is irrevelant because U+FFFD is the unicode replacement character :-D)

If nobody complains about my patch, I will commit it to Python trunk (only).

You can still reimplement fail() method to encode the message using a more revelant encoding and/or error handler.

----------

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

From report at bugs.python.org  Wed May  5 02:37:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:37:11 +0000
Subject: [issue665761] reduce() masks exception
Message-ID: <1273019831.77.0.97711541711.issue665761@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Wed May  5 02:41:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:41:32 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273020092.02.0.881395245821.issue4265@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Wed May  5 02:44:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:44:38 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273020278.46.0.81321341346.issue4265@psf.upfronthosting.co.za>


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

Could you write a test? Use a fake file objects that raise (or not) an IOError on close(), and then check that close() was closed on both files. There are 4 cases: input.close() raises or not an exception, output.close() raises or not an exception.

----------

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

From report at bugs.python.org  Wed May  5 02:45:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 00:45:40 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1273020340.92.0.685843960472.issue2091@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Wed May  5 03:08:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 01:08:26 +0000
Subject: [issue8592] 'y' does not check for embedded NUL bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1273021706.95.0.595372227762.issue8592@psf.upfronthosting.co.za>


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

Same issue for y#:

y# (...) This variant on s# doesn?t accept Unicode objects, only bytes-like objects.

s# (...) The string may contain embedded null bytes.

--

y* might mention that it accepts embedded null bytes.

--

grep 'PyArg_Parse[^"]\+"[^:;)"]*y[^*]' */*.c finds only usage of y# (no usage of y format):

 - mmap_gfind(), mmap_write_method()
 - oss_write(), oss_writeall()
 - in getsockaddrarg() with s->sock_family==AF_PACKET
 - in sock_setsockopt() if the option name is a string
 - socket_inet_ntoa(), socket_inet_ntop()

These functions have to support embedded null bytes. So I think that y# should specify explicitly that embedded null bytes are accepted.

----------
nosy: +haypo

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

From report at bugs.python.org  Wed May  5 03:09:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 01:09:28 +0000
Subject: [issue8592] 'y' does not check for embedded NUL bytes
In-Reply-To: <1272737075.21.0.258918022173.issue8592@psf.upfronthosting.co.za>
Message-ID: <1273021768.06.0.483727225745.issue8592@psf.upfronthosting.co.za>


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

See also #8215.

----------

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

From report at bugs.python.org  Wed May  5 03:09:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 01:09:38 +0000
Subject: [issue8215] getargs.c in Python3 contains some TODO and the
	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1273021778.11.0.987797684029.issue8215@psf.upfronthosting.co.za>


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

See also #8592.

----------

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

From report at bugs.python.org  Wed May  5 03:11:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 01:11:04 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1273021864.16.0.310348110403.issue7472@psf.upfronthosting.co.za>


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

Comments on patch:

We prefer patches to be generated from the top level directory of the checkout, so that it can be applied by doing 'patch -p0 <xxx.patch' from the top level directory without having to look in the patch file to see what directory it was generated in.

The test is correct in general outline, but the thing that needs to be tested is that when a byte string in a character encoding that is eight bit, but whose output encoding (the encoding email will use when writing the message) is 7bit, that 7bit will be chosen for the transfer encoding.  If you look in Lib/email/charsets.py, there are only two such character sets, euc-jp and shift-jis.

We discussed this in IRC, and you found a euc-js character, but then said that the test passed even with the fix removed.  The byte string you are using in the bytes test you posted does not appear to be encodable in the output character set (iso-2022-jp). I'm guessing you used this, and _charset='iso-2022-jp', because otherwise the test passes without the fix.

That is, if put in a character, such as ? ('\xca\xb8' as an euc-jp encoded byte stream), and pass _encoding='euc-jp', the test passes without the fix.  So, you were exactly right in what you said in IRC, and should have posted that version of the unit test :)

Looking at the code even more carefully than I did last time, it turns out that as soon as the 'charset' is set, the payload gets translated from the input character set to the output character set, and *then* encode_7or8bit is called.  As far as I have been able to figure out, there is no way for encode_7or8bit to get called with the payload encoded in the input character set (not even if it is called directly, since it is passed a message instance and so set_charset must already have been called on the message instance it is passed).

So it turns out that the if test is not needed after all.

----------

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

From report at bugs.python.org  Wed May  5 03:40:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 01:40:29 +0000
Subject: [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273023629.38.0.978965048999.issue8617@psf.upfronthosting.co.za>


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

These are references to environment variables.  The markup marks them as such, but this does not translate into HTML in a visible way.  Without a text description it is also left to guesswork as to how they function. The 2.7 docs are even more confusing, adding 'getuserbase'.  Adding Tarek as nosy since he has been updating this doc most recently.

----------
nosy: +r.david.murray, tarek
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 03:41:16 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 05 May 2010 01:41:16 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1273023676.77.0.443770467406.issue7472@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I was getting a feel that the inner if-test is not being used in any case.  Submitting the patch which removes the inner if test and adding a unittest.

----------

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

From report at bugs.python.org  Wed May  5 03:42:33 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 05 May 2010 01:42:33 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1273023753.88.0.716930001761.issue7472@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Added file: http://bugs.python.org/file17215/encoders.patch

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

From report at bugs.python.org  Wed May  5 03:44:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 05 May 2010 01:44:02 +0000
Subject: [issue8615] turtle.py - backport of 3.1 features
In-Reply-To: <1273007699.22.0.180641297375.issue8615@psf.upfronthosting.co.za>
Message-ID: <1273023842.25.0.217703009728.issue8615@psf.upfronthosting.co.za>


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

Feature freeze begins at beta 1, therefore I'm rejecting this.

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

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

From report at bugs.python.org  Wed May  5 05:43:03 2010
From: report at bugs.python.org (Sriram Thaiyar)
Date: Wed, 05 May 2010 03:43:03 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>


New submission from Sriram Thaiyar <sriram.thaiyar at gmail.com>:

http://docs.python.org/dev/py3k/library/urllib.request.html#urllib.request._urlopener

[in the body]
urllib._urlopener should be urllib.request._urlopener

----------
assignee: docs at python
components: Documentation
messages: 104998
nosy: Sriram.Thaiyar, docs at python
priority: normal
severity: normal
status: open
title: Doc bug for urllib.request._urlopener in Python 3.1+
versions: Python 3.1

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

From report at bugs.python.org  Wed May  5 07:35:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 05:35:01 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273037701.59.0.755820309664.issue8619@psf.upfronthosting.co.za>


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

Fixed in r80773 and r80774.

Thanks.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed May  5 08:19:13 2010
From: report at bugs.python.org (sri)
Date: Wed, 05 May 2010 06:19:13 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273040353.06.0.691619317692.issue8619@psf.upfronthosting.co.za>


sri <sriram.thaiyar at gmail.com> added the comment:

You missed the code part:

urllib._urlopener = AppURLopener()

----------

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

From report at bugs.python.org  Wed May  5 09:25:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 07:25:11 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273044311.24.0.704009496428.issue8619@psf.upfronthosting.co.za>


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

Fixed in r80775 and r80776

----------

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

From report at bugs.python.org  Wed May  5 09:45:21 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 07:45:21 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1273016067.99.0.713871493039.issue8610@psf.upfronthosting.co.za>
Message-ID: <4BE1220C.4060500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> I don't think it's a good idea to display an fatal error at runtime. If nl_langinfo(CODESET) is not available, configure should fail or we should fallback to an hardcoded encoding (ok but which one?).

If nl_langinfo(CODESET) fails, Python should assume the default
locale, which is "C" on POSIX platforms. The "C" locale uses
ASCII as encoding, so Python should use that as well. Note that the
manpage for nl_langinfo() doesn't mention any errors that could
be raised by it:

"""
RETURN VALUE
       If  no  locale  has  been  selected  for  the appropriate category, nl_langinfo() returns a
       pointer to the corresponding string in the "C" locale.

       If item is not valid, a pointer to an empty string is returned.

       This pointer may point to static data that may be overwritten on the next call to  nl_lang?
       info() or setlocale(3).
"""

As with all locale APIs, it is not thread-safe, which can become
an issues if Python gets embedded in a multi-threaded application.

There's also another issue: it's possible that nl_langinfo(CODESET)
returns an encoding which is not known to Python.

In such a case, it would be best to issue a warning to the
user and fall back to ASCII as in the "C" locale case.

Terminating Python with a fatal error would provide the worst of
all user experiences. -1 on that.

----------
nosy: +lemburg

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

From report at bugs.python.org  Wed May  5 09:59:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 07:59:47 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1273018801.04.0.0525000713993.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BE12570.4050007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> The documentation of os.environb and os.getenvb() in my last patch is very short. I'm not inspired.
> 
> We told me on IRC to not use function annotations because annotation semantic was not decided yet.
> 
> I will try to improve the documentation and remove the annotations in my next patch.

Patch looks good. +1 on adding it.

One nit: I'd rename the keymap function to encodekey.

----------

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

From report at bugs.python.org  Wed May  5 10:20:02 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 05 May 2010 08:20:02 +0000
Subject: [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273047602.98.0.241582644283.issue8617@psf.upfronthosting.co.za>


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

site definitely needs more documentation about the per-user site-packages. 

We need to add a section about that. I am adding Christian to the nosy list, since he added those feature. I can work on a section sometimes next week and propose a patch here btw.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Wed May  5 10:58:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 08:58:02 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273049882.6.0.568296637609.issue8610@psf.upfronthosting.co.za>


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

> manpage for nl_langinfo() doesn't mention any errors that could
> be raised by it

It's more about get_codeset(). This function can fail for different reasons:

 - nl_langinfo() result is an empty string: "If item is not valid, a pointer to an empty string is returned." say the manpage
 - _PyCodec_Lookup() failed: unable to import the encoding codec module, there is no such codec, codec machinery is broken, etc.
 - the codec has no "name "attribute
 - strdup() failure (no more memory)

Do you think that you should fallback to ASCII if nl_langinfo() result is an empty string, and UTF-8 otherwise? get_codeset() failure is very unlikely, and I think that fallback to UTF-8 is just fine. A warning is printed to stderr, the user should try to understand why get_codeset() failed.

You can at least reproduce the _PyCodec_Lookup() error with #8611.

My problem is also that the file system encoding is required (encoding != None) by os.environ mapping with my os.environb patch. (#8603)

----------

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

From report at bugs.python.org  Wed May  5 11:00:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 09:00:05 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <4BE12570.4050007@egenix.com>
Message-ID: <201005051059.58406.victor.stinner@haypocalc.com>


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

MaL> Patch looks good. +1 on adding it.

Cool. I didn't understood if MvL is +1, but at least he's not -1 on this, and 
we are at least two at +1 :-)

MaL> One nit: I'd rename the keymap function to encodekey.

Ok, I will also change that in the final patch.

----------

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

From report at bugs.python.org  Wed May  5 11:16:44 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 09:16:44 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1273049882.6.0.568296637609.issue8610@psf.upfronthosting.co.za>
Message-ID: <4BE13778.3080108@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> manpage for nl_langinfo() doesn't mention any errors that could
>> be raised by it
> 
> It's more about get_codeset(). This function can fail for different reasons:
> 
>  - nl_langinfo() result is an empty string: "If item is not valid, a pointer to an empty string is returned." say the manpage
>  - _PyCodec_Lookup() failed: unable to import the encoding codec module, there is no such codec, codec machinery is broken, etc.
>  - the codec has no "name "attribute
>  - strdup() failure (no more memory)
> 
> Do you think that you should fallback to ASCII if nl_langinfo() result is an empty string, and UTF-8 otherwise? get_codeset() failure is very unlikely, and I think that fallback to UTF-8 is just fine. A warning is printed to stderr, the user should try to understand why get_codeset() failed.

I think that using ASCII is a safer choice in case of errors.
Using UTF-8 may be safe for reading file names, but it's not
safe for creating files or directories.

I also think that an application should be able to update the
file system encoding in such an error case (and only in such a case).
The application may have better knowledge about how it's being
used and can provide correct encoding information by other means.

----------

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

From report at bugs.python.org  Wed May  5 11:31:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 09:31:05 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273051865.07.0.321860913525.issue8610@psf.upfronthosting.co.za>


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

> I think that using ASCII is a safer choice in case of errors.

I choosed UTF-8 to keep backward compatibility: PyUnicode_DecodeFSDefaultAndSize() uses utf-8 if Py_FileSystemDefaultEncoding==NULL. If the OS has no nl_langinfo(CODESET) function at all, Python3 uses utf-8.

> Using UTF-8 may be safe for reading file names, but it's not
> safe for creating files or directories.

Well, I don't know. You are maybe right. And which encoding should be used if nl_langinfo(CODESET) function is missing: ASCII or UTF-8?

UTF-8 is also an optimist choice: I bet that more and more OS will move to UTF-8.

----------

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

From report at bugs.python.org  Wed May  5 12:00:42 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 05 May 2010 10:00:42 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1273053642.59.0.837799583835.issue8313@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Changing traceback._some_str to return unicode rather than str seems like a bad idea.

----------

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

From report at bugs.python.org  Wed May  5 12:06:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 05 May 2010 10:06:18 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1273053978.18.0.782736870043.issue8313@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------

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

From report at bugs.python.org  Wed May  5 12:07:03 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 10:07:03 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1273051865.07.0.321860913525.issue8610@psf.upfronthosting.co.za>
Message-ID: <4BE14342.2030502@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> I think that using ASCII is a safer choice in case of errors.
> 
> I choosed UTF-8 to keep backward compatibility: PyUnicode_DecodeFSDefaultAndSize() uses utf-8 if Py_FileSystemDefaultEncoding==NULL. If the OS has no nl_langinfo(CODESET) function at all, Python3 uses utf-8.

Ouch, that was a poor choice. In Python we have a tradition to
avoid guessing, if possible. Since we cannot guarantee that the
file system will indeed use UTF-8, it would have been safer to
use ASCII. Not sure why this reasoning wasn't applied for
the file system encoding.

Nothing we can do about now, though.

>> Using UTF-8 may be safe for reading file names, but it's not
>> safe for creating files or directories.
> 
> Well, I don't know. You are maybe right. And which encoding should be used if nl_langinfo(CODESET) function is missing: ASCII or UTF-8?
> 
> UTF-8 is also an optimist choice: I bet that more and more OS will move to UTF-8.

I think we should also add a new environment variable to override
the automatic determination of the file system encoding, much like
what we have for the I/O encoding:

PYTHONFSENCODING: Encoding[:errors] used for file system.

(that would need to go on a new ticket, though)

----------

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

From report at bugs.python.org  Wed May  5 12:19:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 05 May 2010 10:19:58 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1273054798.91.0.591562680393.issue8313@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I would prefer to try str(...) first and only attempt to convert to unicode and do the backslash replace if the str(...) call fails.

----------

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

From report at bugs.python.org  Wed May  5 13:35:56 2010
From: report at bugs.python.org (Mattelaer)
Date: Wed, 05 May 2010 11:35:56 +0000
Subject: [issue8620] wrong truncation of line in Cmd.cmd
In-Reply-To: <1273059355.74.0.713627995995.issue8620@psf.upfronthosting.co.za>
Message-ID: <1273059355.74.0.713627995995.issue8620@psf.upfronthosting.co.za>


New submission from Mattelaer <olivier.mattelaer at uclouvain.be>:

When using the Cmd module on a file. 
it happens that the last line is truncated from the last caracther.

The problem is simply that it can happen that the last line doesn't finish by '\n' charcacter. In consequence the line which is suppose to suppress the '\n' suppress another character.

Cheers,

Olivier

----------
components: None
messages: 105012
nosy: omatt
priority: normal
severity: normal
status: open
title: wrong truncation of line in Cmd.cmd
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 14:00:59 2010
From: report at bugs.python.org (yig)
Date: Wed, 05 May 2010 12:00:59 +0000
Subject: [issue8621] Mac OS X
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>


New submission from yig <yotam at yotamgingold.com>:

Calling uuid.uuid4() while using the multiprocessing module leads to the same exact UUIDs being generating in each process.  It is an artifact resulting from the built-in uuid_generate_random() of my underlying platform, Mac OS X 10.6.3.  A Linux machine I have does not exhibit this problem.  I have tested it with both Python 2.5 and 2.6.

----------
assignee: ronaldoussoren
components: Macintosh
files: multiprocessing_uuid.py
messages: 105013
nosy: ronaldoussoren, yig
priority: normal
severity: normal
status: open
title: Mac OS X
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17216/multiprocessing_uuid.py

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

From report at bugs.python.org  Wed May  5 14:15:34 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 05 May 2010 12:15:34 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273061734.63.0.305566710647.issue8613@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree that the spec is not unambiguous, but consider the Overflow and
Underflow passages here:

http://speleotrove.com/decimal/daexcep.html

  ==> Overflow

    ==> In all cases, Inexact and Rounded will also be raised.


"Raise" here of course means raising the flags Inexact and Rounded,
not Python exceptions. So I would think that if the overflow trap
handler is engaged, the flags Inexact and Rounded must be raised (set
to 1) in the context.

----------

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

From report at bugs.python.org  Wed May  5 14:17:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 12:17:58 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1273061878.26.0.160898410657.issue8211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Since r80665, a

./configure --with-pydebug

seems to give compilation with -O2 (tested on OS X and Linux).  Is this intentional?

I'm getting, e.g.,

gcc -c  -g -O2 -g -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c

----------
nosy: +mark.dickinson
status: closed -> open

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

From report at bugs.python.org  Wed May  5 14:21:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 12:21:46 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273062106.85.0.283345623424.issue8619@psf.upfronthosting.co.za>


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

Why do we have a public API that begins with an '_'?

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 14:27:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 12:27:59 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273062479.55.0.0205355704293.issue8613@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, that's a good point.  It would be nice for e.g. "Inexact => Rounded" invariants to be, well, invariant.

I agree that the cdecimal behaviour is the correct one.  I'm looking for wiggle room here because I don't really want to make a set of complicated and possibly performance-degrading changes to the decimal module unless it's really necessary for correctness.

Having said that, I can see at least one reasonable way of fixing this in the decimal module:

(1) Create a "delay_traps" context manager, so that:

with delay_traps():
    <do arithmetic>

disables traps for the duration of the with block, keeps track of all flags set (disregarding those set before the with block was entered), and then on leaving the with block re-raises signals corresponding to the traps set in the original context (respecting precedence, of course).

(2) Also create a "_delayed_traps" (names could do with improvement, probably) decorator that effectively wraps an entire function in 'with delay_traps()"

(3) Decorate all the primitive decimal operations with this decorator.

Thoughts?

----------

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

From report at bugs.python.org  Wed May  5 14:34:43 2010
From: report at bugs.python.org (yig)
Date: Wed, 05 May 2010 12:34:43 +0000
Subject: [issue8621] Mac OS X
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273062883.37.0.326778525811.issue8621@psf.upfronthosting.co.za>


yig <yotam at yotamgingold.com> added the comment:

For the record, I filed a bug against the underlying platform.  (I wrote a simple program to reproduce this in C and filed a bug report with Apple rdar://7944700.  The OpenRadar page for it is here: http://openradar.appspot.com/radar?id=334401 )

----------

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

From report at bugs.python.org  Wed May  5 14:34:50 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 12:34:50 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1273061878.26.0.160898410657.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BE165E7.4090903@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Since r80665, a
> 
> ./configure --with-pydebug
> 
> seems to give compilation with -O2 (tested on OS X and Linux).  Is this intentional?

Yes. I've restored the previous behavior of configure to
have AC_PROG_CC determine CFLAGS defaults.

Please open a new ticket to have --with-pydebug disable use
of any optimization flags. We need to find a different
solution for that. Unconditionally ignoring the AC_PROG_CC
CFLAGS defaults is not solution.

----------

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

From report at bugs.python.org  Wed May  5 14:35:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 12:35:14 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1273062914.24.0.870199838513.issue8211@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


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

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

From report at bugs.python.org  Wed May  5 14:40:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 12:40:29 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <4BE165E7.4090903@egenix.com>
Message-ID: <4BE1673B.70603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> Mark Dickinson wrote:
>>
>> Mark Dickinson <dickinsm at gmail.com> added the comment:
>>
>> Since r80665, a
>>
>> ./configure --with-pydebug
>>
>> seems to give compilation with -O2 (tested on OS X and Linux).  Is this intentional?
> 
> Yes. I've restored the previous behavior of configure to
> have AC_PROG_CC determine CFLAGS defaults.
> 
> Please open a new ticket to have --with-pydebug disable use
> of any optimization flags. We need to find a different
> solution for that. Unconditionally ignoring the AC_PROG_CC
> CFLAGS defaults is not solution.

Note that using the following line will disable the AC_PROG_CC
defaults:

./configure --with-pydebug CFLAGS=''

This is a new feature that was introduced previously by Victor
and that I corrected in r80665.

----------

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

From report at bugs.python.org  Wed May  5 14:45:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 12:45:32 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273062106.85.0.283345623424.issue8619@psf.upfronthosting.co.za>
Message-ID: <20100505124521.GA6463@remy>


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

That is actually a private attribute of urllib (not urllib2) module
present from the very first version. It is intended strictly for
overriding purposes not for anything else. During the merge in py3k,
it has taken its place in urllib.request. I see no harm in it being
there. If it needs to be un-advertised, perhaps we can remove its
reference from the docs.

----------

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

From report at bugs.python.org  Wed May  5 14:46:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 12:46:31 +0000
Subject: [issue8313] <unprintable AssertionError object> message in unittest
	tracebacks
In-Reply-To: <1270464989.56.0.215414826495.issue8313@psf.upfronthosting.co.za>
Message-ID: <1273063591.37.0.97415758863.issue8313@psf.upfronthosting.co.za>


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

Commited: r80777 (trunk) and r80779 (2.6); blocked: r80778 (py3k).

Open a new issue if you would like to use something better than ASCII+backslashreplace in unittest (using runner stream encoding?).

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

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

From report at bugs.python.org  Wed May  5 15:00:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 13:00:35 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1273064435.62.0.257185751582.issue8211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Yes. I've restored the previous behavior of configure to
> have AC_PROG_CC determine CFLAGS defaults.

Just to be clear, the previous behaviour has *not* been restored.  Up until r80665, a '--with-pydebug' build did not include optimization.  Since r80665, it does.

----------

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

From report at bugs.python.org  Wed May  5 15:18:26 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 13:18:26 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273065506.86.0.0974944899099.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As the bug is in the underlying platform the best we can do is to warn about this in the documentation, as in the attached patch.


BTW. I've updated the title to be slightly more informative.

----------
keywords: +patch
title: Mac OS X -> uuid.uuid4() generates non-unique values on OSX
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file17217/issue8621-doc.patch

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

From report at bugs.python.org  Wed May  5 15:24:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 13:24:03 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1269346447.99.0.323336928566.issue8211@psf.upfronthosting.co.za>
Message-ID: <1273065843.18.0.694261895827.issue8211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, I understand now: -O2 started appearing in debug builds in r79218, which changed the Makefile to respect CFLAGS.  I tested a variety of revision, but failed to test revision in between that and Victor's change...

----------

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

From report at bugs.python.org  Wed May  5 15:26:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 13:26:52 +0000
Subject: [issue8211] configure: allow user-provided CFLAGS to override
	AC_PROG_CC defaults
In-Reply-To: <1273065843.18.0.694261895827.issue8211@psf.upfronthosting.co.za>
Message-ID: <4BE17219.2020008@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Ah, I understand now: -O2 started appearing in debug builds in r79218, which changed the Makefile to respect CFLAGS.  I tested a variety of revision, but failed to test revision in between that and Victor's change...

Right. I was referring to r79391, ie. the state before Victor checked
in his patch.

----------

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

From report at bugs.python.org  Wed May  5 15:32:29 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:32:29 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1273066349.21.0.892263416101.issue4661@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:32:44 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:32:44 +0000
Subject: [issue1467619] Header.decode_header eats up spaces
Message-ID: <1273066364.45.0.506743117557.issue1467619@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:33:01 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:33:01 +0000
Subject: [issue1368247] unicode in email.MIMEText and email/Charset.py
Message-ID: <1273066381.87.0.378700359532.issue1368247@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:33:33 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:33:33 +0000
Subject: [issue1379416] email.Header encode() unicode P2.6
Message-ID: <1273066413.76.0.302577240179.issue1379416@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:34:05 2010
From: report at bugs.python.org (yig)
Date: Wed, 05 May 2010 13:34:05 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273066445.15.0.441000023302.issue8621@psf.upfronthosting.co.za>


yig <yotam at yotamgingold.com> added the comment:

Why not default to not use the Python implementation on darwin instead of the underlying platform's uuid_generate_random(), until it's proven safe?

----------

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

From report at bugs.python.org  Wed May  5 15:34:19 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:34:19 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1273066459.11.0.868858714903.issue6521@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:34:46 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:34:46 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1273066486.32.0.818202019189.issue1685453@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:35:33 2010
From: report at bugs.python.org (yig)
Date: Wed, 05 May 2010 13:35:33 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273066533.36.0.542502839998.issue8621@psf.upfronthosting.co.za>


yig <yotam at yotamgingold.com> added the comment:

Ahem.  Why not use the Python implementation on darwin until its uuid_generate_random() is deemed to be safe?

----------

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

From report at bugs.python.org  Wed May  5 15:35:48 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:35:48 +0000
Subject: [issue1555570] email parser incorrectly breaks headers with a CRLF at
	8192
Message-ID: <1273066548.02.0.965617598229.issue1555570@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:36:31 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:36:31 +0000
Subject: [issue1693546] email.Message set_param rfc2231 encoding incorrect
Message-ID: <1273066591.82.0.564511640343.issue1693546@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
status: pending -> open

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

From report at bugs.python.org  Wed May  5 15:37:37 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:37:37 +0000
Subject: [issue1459867] Message.as_string should use "mangle_from_=unixfrom"?
Message-ID: <1273066657.65.0.988309651289.issue1459867@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:37:58 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:37:58 +0000
Subject: [issue1349106] email.Generators does not separates headers with "\r\n"
Message-ID: <1273066678.26.0.753365835554.issue1349106@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:38:38 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:38:38 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1273066718.62.0.319556338188.issue3244@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> 

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

From report at bugs.python.org  Wed May  5 15:39:06 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:39:06 +0000
Subject: [issue4766] email documentation needs to be precise about
	strings/bytes
In-Reply-To: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za>
Message-ID: <1273066746.68.0.57145761145.issue4766@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:39:27 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:39:27 +0000
Subject: [issue6942] email.generator.Generator memory consumption
In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
Message-ID: <1273066767.19.0.84631253911.issue6942@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:40:29 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:40:29 +0000
Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses
Message-ID: <1273066829.69.0.918167830587.issue1025395@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:41:06 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:41:06 +0000
Subject: [issue1672568] silent error in email.message.Message.get_payload
Message-ID: <1273066866.96.0.466821827543.issue1672568@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:41:25 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:41:25 +0000
Subject: [issue1555842] email package and Unicode strings handling
Message-ID: <1273066885.82.0.7539634122.issue1555842@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:41:50 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:41:50 +0000
Subject: [issue5871] email.header.Header allow to embed raw newlines into a
	message
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1273066910.98.0.0825026318624.issue5871@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:42:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:42:08 +0000
Subject: [issue1440472] email.Generator is not idempotent
Message-ID: <1273066928.95.0.0607070446103.issue1440472@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:42:28 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:42:28 +0000
Subject: [issue724459] Add documentation about line endings in email messages.
Message-ID: <1273066948.25.0.829022357654.issue724459@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:43:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:43:52 +0000
Subject: [issue1078919] Email.Header encodes non-ASCII content incorrectly
Message-ID: <1273067032.03.0.752133760225.issue1078919@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:44:13 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:44:13 +0000
Subject: [issue968430] error flattening complex smime signed message
Message-ID: <1273067053.71.0.0963231546043.issue968430@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:44:34 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:44:34 +0000
Subject: [issue1210680] Split email headers near a space
Message-ID: <1273067074.84.0.0671354318418.issue1210680@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:44:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:44:52 +0000
Subject: [issue1243654] Faster output if message already has a boundary
Message-ID: <1273067092.65.0.440376746557.issue1243654@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:45:09 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:45:09 +0000
Subject: [issue1243730] Big speedup in email message parsing
Message-ID: <1273067109.4.0.861976952063.issue1243730@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:45:25 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:45:25 +0000
Subject: [issue1372770] email.Header should preserve original FWS
Message-ID: <1273067125.97.0.395833395355.issue1372770@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:45:45 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:45:45 +0000
Subject: [issue1690608] email.utils.formataddr() should be rfc2047 aware
Message-ID: <1273067145.76.0.0162660382843.issue1690608@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:46:11 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:46:11 +0000
Subject: [issue1681333] email.header unicode fix
Message-ID: <1273067171.57.0.24471954186.issue1681333@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:46:28 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:46:28 +0000
Subject: [issue504152] rfc822 long header continuation broken
Message-ID: <1273067188.87.0.631480737597.issue504152@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray

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

From report at bugs.python.org  Wed May  5 15:46:47 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:46:47 +0000
Subject: [issue5610] email feedparser.py CRLFLF bug: $ vs \Z
In-Reply-To: <1238435977.23.0.604038870745.issue5610@psf.upfronthosting.co.za>
Message-ID: <1273067207.59.0.899405287823.issue5610@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:47:07 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:47:07 +0000
Subject: [issue5612] whitespace folding in the email package could be better ; 
	-)
In-Reply-To: <1238437516.03.0.51001864383.issue5612@psf.upfronthosting.co.za>
Message-ID: <1273067227.28.0.946717522991.issue5612@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:47:31 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:47:31 +0000
Subject: [issue1590744] mail message parsing glitch
Message-ID: <1273067251.61.0.297227177974.issue1590744@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:47:53 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:47:53 +0000
Subject: [issue1443866] email 3.0+ stops parsing headers prematurely
Message-ID: <1273067273.43.0.439881739602.issue1443866@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:48:18 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:48:18 +0000
Subject: [issue1155362] Bugs in parsedate_tz
Message-ID: <1273067298.88.0.822809897869.issue1155362@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:48:42 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:48:42 +0000
Subject: [issue1043706] External storage protocol for large email messages
Message-ID: <1273067322.97.0.526850725909.issue1043706@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:49:02 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:49:02 +0000
Subject: [issue1050268] rfc822.parseaddr is broken,
	breaks sendmail call in smtplib
Message-ID: <1273067342.13.0.166495173432.issue1050268@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:49:36 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:49:36 +0000
Subject: [issue975330] Inconsistent newline handling in email module
Message-ID: <1273067376.46.0.885251227706.issue975330@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:50:32 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:50:32 +0000
Subject: [issue795081] email.Message param parsing problem II
Message-ID: <1273067432.05.0.449446552547.issue795081@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:50:53 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:50:53 +0000
Subject: [issue4212] email.LazyImporter does not use absolute imports
In-Reply-To: <1225087041.33.0.0357186656553.issue4212@psf.upfronthosting.co.za>
Message-ID: <1273067453.6.0.438521236905.issue4212@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:51:13 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:51:13 +0000
Subject: [issue1525919] email package quoted printable behaviour changed
Message-ID: <1273067473.01.0.886703986165.issue1525919@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:51:58 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:51:58 +0000
Subject: [issue2658] decode_header() fails on multiline headers
In-Reply-To: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za>
Message-ID: <1273067518.36.0.313996930548.issue2658@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:52:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 13:52:07 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273067527.0.0.101388252098.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Because I didn't look closely enough at the source :-(

The attached patch disabled the C implementation on OSX 10.6 or later. I've tested that 10.5 is not affected by the issue.

----------
Added file: http://bugs.python.org/file17218/issue8621.patch

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

From report at bugs.python.org  Wed May  5 15:52:14 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 13:52:14 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273067534.44.0.128752682218.issue8621@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Removed file: http://bugs.python.org/file17217/issue8621-doc.patch

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

From report at bugs.python.org  Wed May  5 15:53:14 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:53:14 +0000
Subject: [issue634412] RFC 2112 in email package
Message-ID: <1273067594.71.0.823303405026.issue634412@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:53:29 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:53:29 +0000
Subject: [issue1443875] email/charset.py convert() patch
Message-ID: <1273067609.33.0.606987635265.issue1443875@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:53:44 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:53:44 +0000
Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on
	email.mime.multipart.MIMEMultipart
In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za>
Message-ID: <1273067624.86.0.924746575749.issue1823@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 15:54:05 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:54:05 +0000
Subject: [issue740495] API enhancement: poplib.MailReader()
Message-ID: <1273067645.36.0.329256024566.issue740495@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> 

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

From report at bugs.python.org  Wed May  5 15:54:50 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 13:54:50 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1273067690.99.0.468525814824.issue7755@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: loewis -> barry

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

From report at bugs.python.org  Wed May  5 15:55:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 13:55:25 +0000
Subject: [issue8622] Add PYTHONFSENCODING environment variable
In-Reply-To: <1273067725.01.0.392024082724.issue8622@psf.upfronthosting.co.za>
Message-ID: <1273067725.01.0.392024082724.issue8622@psf.upfronthosting.co.za>


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

As discussed on issue8610, we need a way to override the automatic detection of the file system encoding - for much the same reasons we also do for the I/O encoding: the detection mechanism isn't fail-safe.

We should add a new environment variable with the same functionality as PYTHONIOENCODING:

    PYTHONFSENCODING: Encoding[:errors] used for file system.

----------
components: Interpreter Core
messages: 105030
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: Add PYTHONFSENCODING environment variable
versions: Python 3.2

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

From report at bugs.python.org  Wed May  5 15:55:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 13:55:57 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273067757.92.0.490803519928.issue8610@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I've opened issue8622 for the env. var idea.

----------

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

From report at bugs.python.org  Wed May  5 15:57:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 13:57:21 +0000
Subject: [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1273067841.93.0.098240155004.issue8538@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Are we sure we want three or four ways to spell the same thing? --foo and --no-foo seem a useful couple to me, and --with-foo/--without-foo cater to different use cases. Perhaps it would be ok to have a SwitchAction (or FlagAction) for --thing/--no-hing and one ConfigureAction for the --with[out]-* style.

----------
nosy: +merwok

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

From report at bugs.python.org  Wed May  5 15:57:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 13:57:36 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>


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

This is on py3k, with gcc 4.4.3:

/home/antoine/py3k/__svn__/Modules/socketmodule.c: In function 'socket_gethostbyaddr':
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3238: warning: dereferencing pointer 'sa' does break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3208: note: initialized from here
/home/antoine/py3k/__svn__/Modules/socketmodule.c: In function 'socket_gethostbyname_ex':
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3183: warning: dereferencing pointer 'sa' does break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3181: note: initialized from here

----------
components: Extension Modules
messages: 105033
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Aliasing warnings in socketmodule.c
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed May  5 15:58:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 13:58:54 +0000
Subject: [issue8624] Aliasing warnings in multiprocessing.c
In-Reply-To: <1273067934.7.0.859212268784.issue8624@psf.upfronthosting.co.za>
Message-ID: <1273067934.7.0.859212268784.issue8624@psf.upfronthosting.co.za>


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

This is on py3k, with gcc 4.4.3:

/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c: In function 'multiprocessing_sendfd':
/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c: In function 'multiprocessing_recvfd':
/home/antoine/py3k/__svn__/Modules/_multiprocessing/multiprocessing.c:168: warning: dereferencing type-punned pointer will break strict-aliasing rules

----------
assignee: jnoller
components: Extension Modules
messages: 105034
nosy: brett.cannon, jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Aliasing warnings in multiprocessing.c
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed May  5 16:03:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 14:03:50 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>


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

When doing a debug build of Python with gcc, without any previous setting of CFLAGS, the '-O2' flag is now automatically included.

This behaviour started in r79218.

It would be nice to restore the original behaviour, if possible, since the optimization causes difficulties when debugging.  One solution would be to add '-O0' to OPT for debug builds (on gcc), as in the attached patch.  You then get compiler flags including:

"-g -O2 -g -O0"

which is somewhat ugly, but the -O0 overrides the -O2 (I think).  Does this seem like a reasonable solution?

----------
components: Build
files: no_debug_optimization.patch
keywords: patch
messages: 105035
nosy: haypo, lemburg, mark.dickinson, pitrou
priority: normal
severity: normal
status: open
title: --with-pydebug builds now include -O2 by default
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17219/no_debug_optimization.patch

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

From report at bugs.python.org  Wed May  5 16:05:53 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 14:05:53 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273068353.78.0.85671043598.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Also added a testcase that should warn if other unix-y platforms start to suffer from the same issue.

BTW. issue8621.patch uses a runtime test in the uuid module instead of a configure-check because a binary might be created on 10.5 (without the issue) and run on 10.6 (with the issue) and that should not result in a broken library.

----------
Added file: http://bugs.python.org/file17220/issue8621-test.patch

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

From report at bugs.python.org  Wed May  5 16:08:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 14:08:32 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273068512.02.0.767719778209.issue8625@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just double checked the gcc manual.  From:

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

"""If you use multiple -O options, with or without level numbers, the last such option is the one that is effective."""

----------

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

From report at bugs.python.org  Wed May  5 16:11:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 14:11:00 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273068802.3512.1.camel@localhost.localdomain>


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

> It would be nice to restore the original behaviour, if possible, since
> the optimization causes difficulties when debugging.  One solution
> would be to add '-O0' to OPT for debug builds (on gcc), as in the
> attached patch.  You then get compiler flags including:
> 
> "-g -O2 -g -O0"
> 
> which is somewhat ugly, but the -O0 overrides the -O2 (I think).  Does
> this seem like a reasonable solution?

Probably good enough.

----------

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

From report at bugs.python.org  Wed May  5 16:21:17 2010
From: report at bugs.python.org (yig)
Date: Wed, 05 May 2010 14:21:17 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273069277.02.0.706756439053.issue8621@psf.upfronthosting.co.za>


yig <yotam at yotamgingold.com> added the comment:

Great work!  Very thorough patches.  Strange that it's a regression versus 10.5.

----------

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

From report at bugs.python.org  Wed May  5 16:28:11 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 05 May 2010 14:28:11 +0000
Subject: [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

Based on the rsplit documentation, I'd expect

  'foo bar'.rsplit(maxsplit=1)

to work.  This is probably a much bigger problem than just rsplit, i.e. I doubt there is a policy about whether documented parameter names need to be usable as keywords, and if not, how one finds out which keywords are supported.

----------
messages: 105040
nosy: dabrahams
priority: normal
severity: normal
status: open
title: TypeError: rsplit() takes no keyword arguments

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

From report at bugs.python.org  Wed May  5 16:30:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 14:30:56 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>


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

Lines 3884 and 3890 of Objects/typeobject.c (trunk, r80782), which check for a subclass overriding __eq__ (or __cmp__) but not __hash__, call PyErr_WarnPy3k but don't check the return value.  [This was reported when compiling Python with clang.] This can lead to an "XXX undetected error", if the warning actually raised an exception:

newton:trunk dickinsm$ ./python.exe -3
Python 2.7b1+ (trunk:80783, May  5 2010, 15:25:42) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
[35022 refs]
>>> warnings.filterwarnings("error")
[35046 refs]
>>> class A(object):
...     def __eq__(self, other):
...         return False
... 
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in 3.x
[35139 refs]

Nick, I think this came from a checkin of yours: r65642, related to issue 2235.  Any suggestions about how to fix it?  It's a bit tricky, since the function the check occurs in (inherit_slots) has return type 'void'.  Is it okay if I change inherit_slots to return an int here?  If so, I'll produce a patch.

Also, can we remove the check related to __hash__ and __cmp__?  With __cmp__ gone in 3.1, and 3.0 considered defunct, I don't think it's relevant any more.

----------
messages: 105041
nosy: mark.dickinson, ncoghlan
priority: normal
severity: normal
status: open
title: Unchecked PyErr_WarnPy3k return value in Objects/typeobject.c
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 16:31:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 14:31:39 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273069899.0.0.850926045976.issue8621@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Wed May  5 16:42:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 14:42:22 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273070542.58.0.611261976433.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with Michael that something should be done.

I propose to add commit os-getgroups-v2.patch, which is the almost same as os-getgroups.patch that I posted earlier, but adds a check for large values of NGROUPS_MAX (see msg99913 for the rationale)

This ensures that os.getgroups() will return a value that is consistent with the id(1) command on OSX and solves the original issue.

Sadly enough this won't fix the other issue that's mentioned in msg99759, because that is a platform issue.  In the current release of OSX it is impossible to both have os.getgroups that reflects calls to os.setgroups and os.getgroups that returns the same information as system tools, and therefore it is my opinion that we should keep the current behavior where we're at least consistent with system tools.

----------

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

From report at bugs.python.org  Wed May  5 16:42:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 14:42:46 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273070566.5.0.0280284445127.issue7900@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Added file: http://bugs.python.org/file17221/os-getgroups-v2.patch

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

From report at bugs.python.org  Wed May  5 16:49:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 14:49:03 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273070943.47.0.27251126155.issue8627@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Fixing this isn't easy:  a simple 'if (inherit_slots(...) < 0) goto error;' produces a huge reference leak in PyType_Ready.

----------

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

From report at bugs.python.org  Wed May  5 16:57:29 2010
From: report at bugs.python.org (Walter Woods)
Date: Wed, 05 May 2010 14:57:29 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273071449.79.0.844376529025.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

Sorry I'm just getting back to this . . . Senthil, doesn't list(None) throw an exception?  That was the whole problem with list()ing the default argument.

And I don't think the problem should be fixed in email.message.Message.get_all() . . . that function works exactly as it says it should.  Its behavior is consistent.  This issue should not change that.  And even WITH changing that function, the patch would still need to fix http.client.HTTPResponse.getheader().  

Just check python 2.6, and it looks like that function works correctly.  If a number is passed, it returns a number as the default.  We'd be preserving backwards compatibility, not destroying it, by returning the default parameter unchanged in 3.X when the specified header does not exist.

I'll try attaching a patch before too long.

----------

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

From report at bugs.python.org  Wed May  5 16:59:27 2010
From: report at bugs.python.org (Thomas Arendsen Hein)
Date: Wed, 05 May 2010 14:59:27 +0000
Subject: [issue1525919] email package quoted printable behaviour changed
Message-ID: <1273071567.26.0.565792163125.issue1525919@psf.upfronthosting.co.za>


Thomas Arendsen Hein <thomas at intevation.de> added the comment:

Roger Demetrescu, I filed the issue with "Python 2.4", because the behavior changed somewhere between 2.4.2 and 2.4.3

The updated link to the MoinMoin bug entry is:
http://moinmo.in/MoinMoinBugs/ResetPasswordEmailImproperlyEncoded

The workaround I use to be compatible with <= 2.4.2 and >= 2.4.3 is:

    msg.set_payload('=')
    if msg.as_string().endswith('='):
        text = charset.body_encode(text)
    msg.set_payload(text)

----------

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

From report at bugs.python.org  Wed May  5 16:59:58 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 05 May 2010 14:59:58 +0000
Subject: [issue8622] Add PYTHONFSENCODING environment variable
In-Reply-To: <1273067725.01.0.392024082724.issue8622@psf.upfronthosting.co.za>
Message-ID: <1273071598.11.0.485396228573.issue8622@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Wed May  5 17:06:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 15:06:24 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273071984.36.0.804984652995.issue8572@psf.upfronthosting.co.za>


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

Walter, just to address one of your point:

+            if failobj and not isinstance(failobj, list):
+                if isinstance(failobj, str):
+                    failobj = [failobj]
+                else:
+                    failobj = list(failobj)
             return failobj   

If the failobj is None, list(None) does not occur here and no exception will be raised. 

Yes, please attach a patch to this issue as you consider would be appropriate. We can see the differences. In py2.6, HTTPResponse.getheader did not invoke get_all method at all, it invokes a geheader method which is a simple dict lookup with default return.

----------
assignee:  -> orsenthil

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

From report at bugs.python.org  Wed May  5 17:08:00 2010
From: report at bugs.python.org (Walter Woods)
Date: Wed, 05 May 2010 15:08:00 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273072080.94.0.486812208287.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

Senthil, you are correct, I gave a bad example.  However, try list()ing an integer :)

----------

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

From report at bugs.python.org  Wed May  5 17:11:51 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 05 May 2010 15:11:51 +0000
Subject: [issue8628] Incorrect numbers.Complex.imag documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The current documentation of the imag abstract property of numbers.Complex is this:
"Abstract. Retrieves the Real component of this number."
Of course the imag attribute is the imaginary component, not the real.

----------
assignee: docs at python
components: Documentation
messages: 105048
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Incorrect numbers.Complex.imag documentation
versions: Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 17:21:55 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 05 May 2010 15:21:55 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273072915.76.0.848125958666.issue8625@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Wed May  5 17:27:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 May 2010 15:27:24 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068802.3512.1.camel@localhost.localdomain>
Message-ID: <4BE18E59.9050703@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> It would be nice to restore the original behaviour, if possible, since
>> the optimization causes difficulties when debugging.  One solution
>> would be to add '-O0' to OPT for debug builds (on gcc), as in the
>> attached patch.  You then get compiler flags including:
>>
>> "-g -O2 -g -O0"
>>
>> which is somewhat ugly, but the -O0 overrides the -O2 (I think).  Does
>> this seem like a reasonable solution?
> 
> Probably good enough.

+1

OPT can also be overridden by the user, to e.g. actually get an
optimized debug build in order to debug compiler optimization
problems.

----------

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

From report at bugs.python.org  Wed May  5 17:31:43 2010
From: report at bugs.python.org (Walter Woods)
Date: Wed, 05 May 2010 15:31:43 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273073503.99.0.307404611137.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

Relevant part from trunk/Lib/rfc822.py illustrating that returning default unchanged is the legacy/defined behavior:

        return self.dict.get(name.lower(), default)

See attached patch for py3k.  This preserves backwards compatibility (aside from the comma-joined list) and uses the default argument appropriately (consistently with the default argument for dict.get, for instance).

On another note, should we be patching Python 2.7 as well, since RFC 2616 states that the 3.X behavior of a comma-joined list is appropriate (as cited  by Senthil)?

----------
Added file: http://bugs.python.org/file17222/issue8572-alt.diff

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

From report at bugs.python.org  Wed May  5 17:34:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 15:34:36 +0000
Subject: [issue8621] uuid.uuid4() generates non-unique values on OSX
In-Reply-To: <1273060858.71.0.68463359774.issue8621@psf.upfronthosting.co.za>
Message-ID: <1273073676.12.0.277438195445.issue8621@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There are way more interesting regressions in OSX, issue8621 is one example: basicly getgroups(2) does not reflect the results of setgroups(2) with the compiler settings we use.

Committed in r80784 (trunk), r80785 (2.6), r80786 (3.2) and r80788 (3.1)

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

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

From report at bugs.python.org  Wed May  5 17:42:18 2010
From: report at bugs.python.org (Walter Woods)
Date: Wed, 05 May 2010 15:42:18 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273074138.98.0.132191452497.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

And if you really think that the unfortunate behavior of 

   >>> getheader('a', ['a', 'b'])
   'a, b'

Is desired, issue8572-unfortunate.diff retains that behavior.  I think that is counter-intuitive though, and it is doubtful that many would be relying on this functionality, given that the default value of None throws an exception at the moment.

----------
Added file: http://bugs.python.org/file17223/issue8572-unfortunate.diff

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

From report at bugs.python.org  Wed May  5 17:51:07 2010
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 05 May 2010 15:51:07 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273074667.67.0.225331497661.issue4265@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I would be glad to write those tests, if you could explain the strategy you have in mind more fully:  since 'shutil.copyfile' performs the 'open' itself, I couldn't figure out how to stub in such a mocked up file.

Does 'open' provide a hook for testing purposes that I don't know about?

----------

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

From report at bugs.python.org  Wed May  5 18:18:41 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 05 May 2010 16:18:41 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1273076321.7.0.064851305945.issue7755@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

trunk: r80793
py3k: 80795

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

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

From report at bugs.python.org  Wed May  5 18:20:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 16:20:40 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>
Message-ID: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>


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

OpenSSL 1.0.0 needs to change the cipher list for some test_ssl tests to succeed, but the cipher list can't be changed in 2.6/3.1 (maintenance branches). The solution is to skip these tests with the newer OpenSSLs.

This patch uses the "openssl" executable to fetch the OpenSSL version, but we could instead backport OPENSSL_VERSION_* from trunk, at least as  undocumented attributes. What do you think?

----------
components: Tests
files: sslfix.patch
keywords: patch
messages: 105055
nosy: giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file17224/sslfix.patch

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

From report at bugs.python.org  Wed May  5 18:25:00 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 05 May 2010 16:25:00 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>
Message-ID: <1273076700.81.0.599935861775.issue8629@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Wed May  5 18:33:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 16:33:20 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1273077200.59.0.0263020981812.issue3244@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Wed May  5 18:36:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 16:36:24 +0000
Subject: [issue740495] API enhancement: poplib.MailReader()
Message-ID: <1273077384.42.0.823596476508.issue740495@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray

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

From report at bugs.python.org  Wed May  5 18:38:19 2010
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_M=2E_C=2E_Campos?=)
Date: Wed, 05 May 2010 16:38:19 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>


New submission from Andr? M. C. Campos <amccampos at gmail.com>:

Some methods in StreamReaderWriter class (codecs library) has different signatures from StreamReader methods. More precisely it's missing the keepends parameter in readline and readlines methods.

So, we cannot code:
fp = codecs.open(fileName, "r", "utf-8")
lines = fp.readlines(keepends=False)
or
line = fp.readline(keepends=False)

----------
components: Library (Lib)
messages: 105056
nosy: amccampos
priority: normal
severity: normal
status: open
title: Keepends param in codec readline(s)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 18:43:55 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Wed, 05 May 2010 16:43:55 +0000
Subject: [issue7583] Improve explanation of tab expansion in doctests
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1273077835.53.0.797251040891.issue7583@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

I've just been bitten by this, and I agree the language in the docs is very inappropriate (made me angry for a minute :)). 

One suggestion: "While not everyone might believe tabs should mean that, doctests are primarily aimed at documentation, and, since it's very hard to get tabs to look consistent, keeping hard tabs would be potentially confusing. If you absolutely need to test for the presence of tabs at the output, you can capture it and use string comparison, or write your own DocTestParser class."

----------
nosy: +rbp

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

From report at bugs.python.org  Wed May  5 18:44:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 16:44:11 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1273077851.04.0.172259371147.issue8550@psf.upfronthosting.co.za>


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

New patch after reindent of _ssl.c

----------
Added file: http://bugs.python.org/file17225/sslcontext3.patch

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

From report at bugs.python.org  Wed May  5 18:53:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 16:53:16 +0000
Subject: [issue8628] Incorrect numbers.Complex.imag documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273078396.54.0.220338727539.issue8628@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed May  5 19:06:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 17:06:02 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1273079162.66.0.267619287788.issue8573@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Don?t want to bikeshed here, but why didn?t you keep the newer ?{}? string formatting? Module consistency?

----------
nosy: +merwok

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

From report at bugs.python.org  Wed May  5 19:12:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 17:12:43 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273079563.88.0.15544827708.issue8572@psf.upfronthosting.co.za>


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

Given what we've learned, I think that Walter's first patch is the best fix.  No one should be relying on the current actual behavior of the default argument, and the fix makes it work as documented.

As for backporting to 2.7, I don't think so.  2.7 is in feature freeze, and the API change would be a feature and not a bug fix.  (You could argue that, though, based on the RFC...so someone can appeal to Benjamin if desired.)

Walter, re the patch, why pass a default to get_all at all?  It is going to return None if there are no such headers.  Then you could test 'if headers is None' and the logic would be a little more pedantically safe.

Also, we need some unit tests for this.

----------

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

From report at bugs.python.org  Wed May  5 19:24:19 2010
From: report at bugs.python.org (Walter Woods)
Date: Wed, 05 May 2010 17:24:19 +0000
Subject: [issue8572] httplib getheader() throws error instead of default
In-Reply-To: <1272556633.35.0.699750313989.issue8572@psf.upfronthosting.co.za>
Message-ID: <1273080259.88.0.275127273776.issue8572@psf.upfronthosting.co.za>


Walter Woods <woodswalben at gmail.com> added the comment:

I'll add unit tests later if no one else gets to it first; and they have the same functionality, but I could change the default back to None and use is None if that would be clearer (it would).

----------

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

From report at bugs.python.org  Wed May  5 19:27:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 17:27:30 +0000
Subject: [issue8564] Update documentation on doctest/unittest2 integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1273080450.01.0.363692473609.issue8564@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can?t tell if the code is correct (we can trust Michael about that), but the wording and the content are ok for me.

----------
nosy: +merwok

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

From report at bugs.python.org  Wed May  5 19:50:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 17:50:29 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1273081829.71.0.0468287543449.issue7472@psf.upfronthosting.co.za>


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

Committed to trunk in r80800.

However, when I ported it to py3k, it turns out the test fails there, but passes if the original fix from this issue has been applied.  More investigation is needed, but clearly something changed in the payload encoding logic (which is not too surprising).

----------

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

From report at bugs.python.org  Wed May  5 20:04:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 18:04:33 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273082673.21.0.797924278172.issue8619@psf.upfronthosting.co.za>


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

Mainly I'm saying that I don't think a public API should have a name starting with an '_'.  Sets a bad precedent :)

Looking at the functionality more closely, though, it does make me nervous that we are recommending changing the global state of the module.  Sounds like a recipe for hard to find bugs.  So maybe it should be removed from the docs, and a better way found to expose that functionality.

----------

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

From report at bugs.python.org  Wed May  5 20:08:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 18:08:50 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273082930.98.0.982414145414.issue8630@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +lemburg

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

From report at bugs.python.org  Wed May  5 20:22:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 May 2010 18:22:57 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273083777.56.0.0331504181137.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The latest patch, os-getgroups-v2.patch, seems to have the same bug as I reported in msg99926:

"""
The crash that I see is apparently due to underallocated  memory:

 alt_grouplist = PyMem_Malloc(n);

should be

 alt_grouplist = PyMem_Malloc(n * sizeof(gid_t));
"""

I no longer see the crash, but did not have a chance to investigate it further.  In any case, PyMem_Malloc(n) is clearly wrong and should be replaced by PyMem_Malloc(n * sizeof(gid_t)) or maybe better by PyMem_New(gid_t, n).

There are no tests in the patch and issue7900-tests.diff tests return "FAILED (failures=3, errors=2)" when ran as a superuser.

----------
nosy: +belopolsky -Alexander.Belopolsky
stage: patch review -> unit test needed

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

From report at bugs.python.org  Wed May  5 20:30:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 18:30:58 +0000
Subject: [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1273084258.45.0.531730373538.issue8600@psf.upfronthosting.co.za>


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

I've committed the patch in r80802 (trunk) and r80803 (py3k).

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

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

From report at bugs.python.org  Wed May  5 20:41:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 May 2010 18:41:31 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273084891.99.0.0387150855857.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ronald> How did you detect that the modern getgroups implementation
Ronald> doesn't query the kernel? That would be very odd.

I have just found the source code for getgroups:

http://www.opensource.apple.com/source/Libc/Libc-594.1.4/sys/getgroups.c

As I suspected, it simply calls getgrouplist with the current user name.

>From getgrouplist(3) manpage:

"""
The getgrouplist() function reads through the group file and calculates the group access list for the user specified in name. 
"""

----------

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

From report at bugs.python.org  Wed May  5 20:45:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 May 2010 18:45:10 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>
Message-ID: <1273085110.02.0.138757082812.issue8629@psf.upfronthosting.co.za>


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

I don't think we should use the openssl binary for anything. It may belong to a different version, and it may not be available (in particular on Windows).

I don't understand the problem you are trying to solve. What exactly is it that will stop working on OpenSSL 1.0?

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

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

From report at bugs.python.org  Wed May  5 20:51:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 18:51:09 +0000
Subject: [issue8605] gdb API issues
In-Reply-To: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>
Message-ID: <1273085469.22.0.0444181194757.issue8605@psf.upfronthosting.co.za>


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

My intuition about an API problem seems to be mistaken. If I compile Python in debug mode without any optimizations ("CFLAGS='' ./configure --with-pydebug"), all tests pass. The default builds of Python use -O2 nowadays, even in debug mode (issue8625), which makes some of the tests fail.

Perhaps test_gdb, or some of its tests, should be skipped when compiler optimizations were enabled. Now we have to find out how to get that information.

----------

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

From report at bugs.python.org  Wed May  5 20:52:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 18:52:42 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273085110.02.0.138757082812.issue8629@psf.upfronthosting.co.za>
Message-ID: <1273085706.3499.6.camel@localhost.localdomain>


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

> I don't think we should use the openssl binary for anything. It may
> belong to a different version, and it may not be available (in
> particular on Windows).

Agreed.

> I don't understand the problem you are trying to solve. What exactly
> is it that will stop working on OpenSSL 1.0?

OpenSSL 1.0.0 disables SSLv2 by default, which means the protocol
combination tests give different results (for example, an SSLv23 client
will refuse talking to an SSLv2 server, because the client will attempt
an SSLv3 hello).

We need therefore to fix these tests, by differentiating their outcomes
depending on the OpenSSL version.

(trunk and py3k use a different approach: they manually enable SSLv2
ciphers in those tests, using the new "ciphers" argument, which makes
the behaviour consistent accross all OpenSSL versions)

----------

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

From report at bugs.python.org  Wed May  5 20:52:56 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 05 May 2010 18:52:56 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273085576.08.0.986483904898.issue8627@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I just came across the warning myself (after ignoring all the PyType_INIT() warnings; what to do about those?) and came to the same conclusion: it's a pain to fix.

One option is to do a PyErr_Occurred() check at inherit_slots() call sites. Would that mitigate the leak? If I remember correctly inherit_slots() is not called constantly (only when a type is being created?) so having the expensive PyErr_Occurred() call should not hurt performance.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Wed May  5 20:54:21 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 05 May 2010 18:54:21 +0000
Subject: [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1273085661.45.0.124139983234.issue8626@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +easy
stage:  -> unit test needed

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

From report at bugs.python.org  Wed May  5 20:58:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 May 2010 18:58:32 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273085706.3499.6.camel@localhost.localdomain>
Message-ID: <4BE1BFD5.5040000@v.loewis.de>


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

> OpenSSL 1.0.0 disables SSLv2 by default, which means the protocol
> combination tests give different results (for example, an SSLv23 client
> will refuse talking to an SSLv2 server, because the client will attempt
> an SSLv3 hello).

I see. I think we should just remove that test, then, as it is not
longer a feature of the Python SSL support that we can maintain.

Notice that we should *not* test OpenSSL - hopefully, they have their
own test suites. Instead, we should only test the Python integration of
OpenSSL. Therefore, we should only write test cases that work
independent of the OpenSSL version (except when some API that we want to
test is not available in older OpenSSL versions, in which case a
testable way for that absence should be added when the API gets added).

In short: just remove the test cases whose outcome depend on the OpenSSL
version.

----------

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

From report at bugs.python.org  Wed May  5 21:02:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 19:02:52 +0000
Subject: [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1273086172.81.0.0397276132817.issue8556@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Wed May  5 21:05:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 19:05:59 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273086359.69.0.0346816179544.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The PyMalloc error was a lame bug. I've also fixed another issue (missing parenthesis in an error return).

os-getgroups-v3.patch also adds unittests: 
* issue7900-tests.diff, but with all tests disabled on darwin (due to the broken implementation of getgroups) 
* a check that verifies that the result of os.getgroups is consistent with "id -G". This one is only tested on darwin because parsing the output of commands is fragile and I'm far from sure that the test will work on other platforms.

----------

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

From report at bugs.python.org  Wed May  5 21:09:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 19:09:58 +0000
Subject: [issue8605] test_gdb can fail with compiler opts
In-Reply-To: <1272903293.59.0.249639149559.issue8605@psf.upfronthosting.co.za>
Message-ID: <1273086598.19.0.131996994086.issue8605@psf.upfronthosting.co.za>


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

Here is a patch which skips test_gdb when Python was built with something else than -O0.

----------
keywords: +patch
title: gdb API issues -> test_gdb can fail with compiler opts
Added file: http://bugs.python.org/file17226/gdbopts.patch

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

From report at bugs.python.org  Wed May  5 21:12:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 19:12:47 +0000
Subject: [issue7908] remove leftover macos9 support code
In-Reply-To: <1265898907.53.0.125133680219.issue7908@psf.upfronthosting.co.za>
Message-ID: <1273086767.53.0.163828309862.issue7908@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Removed traces of MacOS9 support in r80804 (trunk) and r80805 (3.2)

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

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

From report at bugs.python.org  Wed May  5 21:13:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 19:13:33 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <4BE1BFD5.5040000@v.loewis.de>
Message-ID: <1273086956.3499.9.camel@localhost.localdomain>


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

> Notice that we should *not* test OpenSSL - hopefully, they have their
> own test suites. Instead, we should only test the Python integration of
> OpenSSL. Therefore, we should only write test cases that work
> independent of the OpenSSL version (except when some API that we want to
> test is not available in older OpenSSL versions, in which case a
> testable way for that absence should be added when the API gets added).

I agree that these tests are more integration tests than unit tests;
however, they are useful in exercising the code and options we provide
(otherwise we wouldn't know whether e.g. PROTOCOL_TLSv1 really does what
it claims to do).

I think we can simply skip these tests in maintenance branches, where we
don't provide the necessary API to make them pass reliably.

----------

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

From report at bugs.python.org  Wed May  5 21:14:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 19:14:34 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1273086874.97.0.824842092345.issue7904@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I remember seeing a discussion on python-dev archives about that months or years ago. Someone pointed to Guido that the new RFC removed the need for uses_netloc thanks to the generic syntax. Isn?t there already a bug about that?

----------
nosy: +merwok

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

From report at bugs.python.org  Wed May  5 21:34:50 2010
From: report at bugs.python.org (Ammon Riley)
Date: Wed, 05 May 2010 19:34:50 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273088090.42.0.399430807086.issue4265@psf.upfronthosting.co.za>


Ammon Riley <ammon.riley at gmail.com> added the comment:

You can replace the built-in open(), with one of your own devising:

    >>> import shutil
    >>> def open(*a, **k):
    ...   raise IOError("faked error.")
    ...
    >>> __builtins__.open = open
    >>> shutil.copyfile("snake", "egg")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.6/shutil.py", line 52 in copyfile
        fsrc = open(src, 'rb')
    File "<stdin>", line 2, in open
    IOError: faked error.

Note that your open() replacement will need a bit of smarts, 
since it needs to succeed for some open() calls, and fail for
others, so you'll want to stash the original __builtins__.open()
for future use.

----------

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

From report at bugs.python.org  Wed May  5 21:35:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 19:35:05 +0000
Subject: [issue6521] Contradictory documentation for email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1273088105.86.0.58941642881.issue6521@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


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

From report at bugs.python.org  Wed May  5 21:43:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 May 2010 19:43:24 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1273018801.04.0.0525000713993.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BE1CA58.4090109@v.loewis.de>


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

> @loewis: So do you agree to add os.environb and os.getenvb()?

I agree with the patch (-2) in principle. I think the error handling
needs to improve:

py> os.getenvb('PATH')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/martin/work/3k/Lib/os.py", line 484, in getenvb
    return environb.get(key, default)
  File "/home/martin/work/3k/Lib/_abcoll.py", line 357, in get
    return self[key]
  File "/home/martin/work/3k/Lib/os.py", line 400, in __getitem__
    value = self.data[self.encodekey(key)]
TypeError: string argument without an encoding

which then leads to the natural, but incorrect

py> os.getenvb('PATH', encoding='ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: getenvb() got an unexpected keyword argument 'encoding'

The first error should remain TypeError, but say something like
"unsupported type string", or "bytes expected".

I notice an incompatible change: posix.environ has now a different
element type. This is probably fine.

There is a couple of white-space only changes in the patch; it would be
good if you could reduce them.

----------

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

From report at bugs.python.org  Wed May  5 21:47:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 05 May 2010 19:47:57 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1273088877.48.0.705858004562.issue6763@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The script works fine for me (OSX 10.6.3, /usr/bin/python2.5, /usr/bin/python2.6, a recent build of 2.6.x, a recent build of 3.2 and the trunk)

The breakit example in msg93828 works in 64-bit binaries, and fails on 32-bit ones. This is almost certainly a stack overrun: I can remove the crash by increasing the stacksize using thread.stacksize(N) for a sufficiently large value of N.  (I don't mention a value for N because I don't know yet what the minimum size is to avoid the crash).

There are three possible actions w.r.t. this:

1) Ignore the issue (users can call thread.stack_size when they
   want deep recursion in threads)

2) Reduce the recursion limit on OSX to something that fits in the 
   default stack size of pthread

3) Increase the default stack size for new threads.

I have a slight preference for the first choice, although the last choice would be fine too. Reducing the recursion limit would also harm code that uses deep recursion on the main thread, which is why I'd be -1 on that.

----------

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

From report at bugs.python.org  Wed May  5 21:56:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 May 2010 19:56:15 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273086956.3499.9.camel@localhost.localdomain>
Message-ID: <4BE1CD5B.5050507@v.loewis.de>


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

> I agree that these tests are more integration tests than unit tests;
> however, they are useful in exercising the code and options we provide
> (otherwise we wouldn't know whether e.g. PROTOCOL_TLSv1 really does what
> it claims to do).

I don't think the test actually achieves that, as we are testing against
our own implementation (IIUC). To be sure that this really triggers the
right bytes on the wire, we would have to test against an independent
TLS implementation.

----------

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

From report at bugs.python.org  Wed May  5 22:09:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 20:09:46 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <4BE1CD5B.5050507@v.loewis.de>
Message-ID: <1273090330.27648.0.camel@localhost.localdomain>


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

> I don't think the test actually achieves that, as we are testing against
> our own implementation (IIUC). To be sure that this really triggers the
> right bytes on the wire, we would have to test against an independent
> TLS implementation.

Yes, it's a best effort thing.

----------

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

From report at bugs.python.org  Wed May  5 22:21:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 20:21:53 +0000
Subject: [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1273090913.63.0.873848285373.issue8626@psf.upfronthosting.co.za>


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

This is more of a documentation issue than anything else. The fact that the argument is named "maxsplit" and accepts a default value doesn't mean it's usable as a keyword argument. It would be difficult to document a parameter without giving it a name anyway...

As a rule of thumb, methods accepting 2 parameters or less often don't accept any keyword arguments, since there's no point in doing so.

I suggest closing this issue.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
stage: unit test needed -> 

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

From report at bugs.python.org  Wed May  5 22:23:53 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 05 May 2010 20:23:53 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1273091033.25.0.390040104355.issue8390@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I think it is a good suggestion to use "surrogateescape" as the default, because (I hope) it produces the fewest errors and is the best choice if tarfile is used in connection with Python's filesystem calls.

- When reading tar headers, undecodable chars in filenames end up as surrogates. This way no information is lost. In principle tarfile is merely a gateway to a filesystem inside an archive, so it feels natural if it treats filenames the same as Python's filesystem calls.

- When writing tar headers, filenames with surrogate chars (e.g. from os.listdir()) will be converted back to bytes in the header (in case of gnu and ustar formats). Filenames will remain unchanged, this is exactly as one would expect.

- When writing pax headers, filenames with surrogates will raise a UnicodeError because we may only use strict utf-8 inside a pax header. This is actually no difference to the status quo.

@Martin: As I understand it, the pax "invalid"-option is supposed to deal with the case when strings from a pax header are not representable in the user's encoding. In tarfile's case we don't have this problem when reading the archive until we try to extract it.

Unfortunately, POSIX says nothing about how to store bad filenames in a pax archive. tarfile raises an error. GNU tar fails silently, it just puts the unchanged original filename into the pax header without converting it to utf-8, thus violating the standard.

----------
Added file: http://bugs.python.org/file17227/tarfile_surrogates.2.diff

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

From report at bugs.python.org  Wed May  5 22:39:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 May 2010 20:39:24 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273091964.81.0.853381365911.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ronald,

Did you forget to attach your patch? I don't see v3.

----------

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

From report at bugs.python.org  Wed May  5 23:31:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 21:31:11 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1273095071.76.0.822414070534.issue8533@psf.upfronthosting.co.za>


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

Reopen: r80703 (and r80711) introduces a new bug: on Windows, there is an empty string between each line. It looks like a newline error.

replace_stdout() should set the newline argument to open(). But how can I get the newline attribute from sys.stdout? sys.stdout._writenl?

regrtest_stdout_newline.patch should fix the newline problem.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file17228/regrtest_stdout_newline.patch

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

From report at bugs.python.org  Wed May  5 23:45:07 2010
From: report at bugs.python.org (Alex Quinn)
Date: Wed, 05 May 2010 21:45:07 +0000
Subject: [issue8631] subprocess.Popen.communicate(...) hangs on Windows
In-Reply-To: <1273095906.37.0.582736332431.issue8631@psf.upfronthosting.co.za>
Message-ID: <1273095906.37.0.582736332431.issue8631@psf.upfronthosting.co.za>


New submission from Alex Quinn <aq2009 at alexquinn.org>:

After using subprocess.Popen(...).communicate(), the session hangs.

c:\>python31
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.
>>> from subprocess import Popen, PIPE
>>> Popen(["echo","Hello!"], stdout=PIPE).communicate()[0]
b'Hello!\n'
>>>

At this point, the session stops responding to keyboard input.



=========================================
MORE DETAILS:

Neither Ctrl-C, Ctrl-Z, nor Ctrl-D will break out of it, but Ctrl-Break does break out of it.

The task manager shows no CPU activity for the process.

I've seen problem with Python v3.1.2 and v2.6.1 on Windows 7.

It works fine under Linux:

$ python3.1
Python 3.1 (r31:73572, Mar 22 2010, 14:57:00)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> Popen(["echo","Hello!"], stdout=PIPE).communicate()[0]
b'Hello!\n'
>>> print("No problems under Linux")
No problems under Linux
>>>

Is this bug type "crash" or "behavior"?  I went with the former, since it ends the usable Python session.

----------
components: IO, Library (Lib), Windows
messages: 105088
nosy: Alex Quinn
priority: normal
severity: normal
status: open
title: subprocess.Popen.communicate(...) hangs on Windows
type: crash
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed May  5 23:55:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 21:55:20 +0000
Subject: [issue8628] Incorrect numbers.Complex.imag documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273096520.22.0.853425359723.issue8628@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!  Fixed in r80826 through r80829.

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

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

From report at bugs.python.org  Wed May  5 23:59:21 2010
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 05 May 2010 21:59:21 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273096761.96.0.650714109943.issue4265@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

This patch adds tests for the four edge cases (opening source fails, opening dest fails, closing dest fails, closing source fails).

----------
Added file: http://bugs.python.org/file17229/issue4265-test_copyfile_exceptions.patch

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

From report at bugs.python.org  Thu May  6 00:04:25 2010
From: report at bugs.python.org (Alex Quinn)
Date: Wed, 05 May 2010 22:04:25 +0000
Subject: [issue8632] subprocess doesn't handle Windows built-in commands as
	os.system() does
In-Reply-To: <1273097065.69.0.229964904727.issue8632@psf.upfronthosting.co.za>
Message-ID: <1273097065.69.0.229964904727.issue8632@psf.upfronthosting.co.za>


New submission from Alex Quinn <aq2009 at alexquinn.org>:

The documentation says subprocess replaces os.system().  However, subprocess does not handle built-in Windows shell commands as os.system() does.

Works:
- os.system("dir /w")
- subprocess.Popen("cmd /c dir /w", stdout=subprocess.PIPE).communicate()[0]

Does NOT work:
- Popen("dir /w", stdout=PIPE).communicate()[0]
- Popen(["dir", "/w"], stdout=PIPE).communicate()[0]

Examples:
s:\d>python31
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.
>>> from subprocess import Popen, PIPE
>>> Popen(["cmd", "/c", "dir", "/w"], stdout=PIPE).communicate()[0]
   .....  (WORKED)
>>> Popen(["dir", "/w"], stdout=PIPE).communicate()[0]
dir: cannot access /w: No such file or directory
b''       (DIDN'T WORK)
>>>

----------
components: IO, Library (Lib), Windows
messages: 105091
nosy: Alex Quinn
priority: normal
severity: normal
status: open
title: subprocess doesn't handle Windows built-in commands as os.system() does
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu May  6 00:07:40 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 May 2010 22:07:40 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273097260.94.0.991006635428.issue8627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I haven't looked at this in a while, but I do remember it was hard to get working at all without a ridiculous number of false alarms - type initialisation isn't the most straightforward thing in the world.

Agreed the warning for __cmp__ should just go away - I think we nuked the actual check in 3.1 when __cmp__ was removed, but must have missed this at the time.

For the refleak, I'm wondering if you may be seeing a problem with statically allocated type objects. type_new does a DECREF on the allocated object if PyType_Ready fails, so everything should be getting cleaned up at that point, but that won't happen for a statically allocated type.

Looking at type_clear, I suggest sticking a "Py_CLEAR(type->tp_mro);" in before the goto error line and see if that eliminates the leak. If that actually works, then I'll have my doubts about the correctness of the other "goto error" lines in PyType_Ready that happen after the call to mro_internal().

----------

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

From report at bugs.python.org  Thu May  6 00:09:53 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 05 May 2010 22:09:53 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273097393.31.0.137309924267.issue8627@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Not sure how relevant my second last paragraph is - I meant to take that out after noticing the MRO details).

----------

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

From report at bugs.python.org  Thu May  6 00:14:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 22:14:51 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>


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

tarfile is unable to open a TAR archive in PAX format embedding invalid filenames (filename not encoded in utf8, an undecodable filename). Attached file is an example (contain the file b'z/\xff', not decodable from utf8).

PAX specification has a "invalid" option with 4 values: bypass (default), rename, UTF-8, write.
http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html

As it was done for other formats in issue #8390, PAX can use Python surrogateescape error handler to store undecodable bytes as unicode surrogates.

I think that PAX should be strict by default, but have an option to enable surrogateescape mode.

----------
components: Library (Lib)
files: z-pax.tar
messages: 105094
nosy: haypo, lars.gustaebel, loewis
priority: normal
severity: normal
status: open
title: tarfile doesn't support undecodable filename in PAX format
versions: Python 3.2
Added file: http://bugs.python.org/file17230/z-pax.tar

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

From report at bugs.python.org  Thu May  6 00:15:19 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 05 May 2010 22:15:19 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1273097719.89.0.560435802136.issue8404@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

(commenting on a closed bug, because I'm not sure it should be re-opened)

While coming up with examples, I found a weird inconsistency.  Was it intentional for viewkeys() and viewitems() to support set operations, but not viewvalues()? 

>>> d1 = dict((i*10, chr(65+i)) for i in range(26))
>>> d2 = dict((i**.5, i) for i in range(1000))
>>> d1.viewkeys() | set('abc')
set([0, 130, 10, 140, 20, 150, 30, 160, 40, 170, 50, 180, 60, 190, 70, 200, 80, 210, 90, 220, 'a', 'c', 'b', 100, 230, 110, 240, 120, 250])
>>> d1.viewitems() | set('abc')
set([(70, 'H'), (0, 'A'), ....)
>>> d1.viewvalues() | set('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'dict_values' and 'set' 
>>> d1.viewvalues() | d2.viewvalues()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'dict_values' and 'dict_values'

----------

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

From report at bugs.python.org  Thu May  6 00:15:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 22:15:23 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1273097723.44.0.255170626381.issue8390@psf.upfronthosting.co.za>


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

Thank you for your review. I commited the patch as r80824 (I fixed the documentation, :versionadded => :versionchanged), blocked as r80825 (3.2).

--

> Unfortunately, POSIX says nothing about how to store bad filenames in
> a pax archive. tarfile raises an error. GNU tar fails silently,
> it just puts the unchanged original filename into the pax header
> without converting it to utf-8, thus violating the standard.

Right. I opened a new issue about that: #8333. I consider that it's a different problem.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Thu May  6 00:19:24 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 05 May 2010 22:19:24 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1273097964.36.0.553935984298.issue8404@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The fix is easy, I think; just add Py_TPFLAGS_CHECKTYPES to the PyDictValues_Type's definition.

----------

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

From report at bugs.python.org  Thu May  6 00:25:23 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 05 May 2010 22:25:23 +0000
Subject: [issue8632] subprocess doesn't handle Windows built-in commands as
	os.system() does
In-Reply-To: <1273097065.69.0.229964904727.issue8632@psf.upfronthosting.co.za>
Message-ID: <1273098323.48.0.469580798056.issue8632@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

shell commands don't work because you're not specifying the shell=True argument to Popen. This is covered in the subprocess "Replacing os.system" documentation

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

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

From report at bugs.python.org  Thu May  6 00:27:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 22:27:43 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1273098463.61.0.760412096962.issue8407@psf.upfronthosting.co.za>


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

> pthread_sigmask should be used instead.  I could either expose both of > these and let the caller choose, or I could make signal.sigprocmask use > pthread_sigmask if it's available, and fall back to sigprocmask.

Or perhaps you could disable the feature if pthread_sigmask isn't available. Apparently, FreeBSD and Mac OS X have it, as well as Linux.

----------

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

From report at bugs.python.org  Thu May  6 00:28:51 2010
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 05 May 2010 22:28:51 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1273098531.68.0.950320821681.issue8407@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

Trying pthread_sigmask first, and falling back, seems like the right strategy to me.

----------
nosy: +tseaver

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

From report at bugs.python.org  Thu May  6 00:30:21 2010
From: report at bugs.python.org (Alex Quinn)
Date: Wed, 05 May 2010 22:30:21 +0000
Subject: [issue8632] subprocess doesn't handle Windows built-in commands as
	os.system() does
In-Reply-To: <1273097065.69.0.229964904727.issue8632@psf.upfronthosting.co.za>
Message-ID: <1273098621.76.0.99567194317.issue8632@psf.upfronthosting.co.za>


Alex Quinn <aq2009 at alexquinn.org> added the comment:

Sorry.  My mistake.  Thanks for clarifying.

----------

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

From report at bugs.python.org  Thu May  6 00:32:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 May 2010 22:32:26 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273098746.98.0.38816590503.issue8633@psf.upfronthosting.co.za>


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

I think you are misinterpreting the spec. A PAX file MUST encode its file names in UTF-8. The "invalid" flag only applies when these invalid names cannot map to file names - either because they are not supported in the locale, or because they are not supported by the file system on which you want to extract the files (e.g. if they contain a colon ':' and you try to extract to a FAT filesystem).

The case that the file names are not actually in UTF-8 in the PAX file is a format error, just like any other format error in the file.

----------

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

From report at bugs.python.org  Thu May  6 00:33:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 22:33:54 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273098834.63.0.321717818013.issue8625@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r80832 (trunk), r80834 (py3k).  Thanks, all.

----------
assignee:  -> mark.dickinson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu May  6 00:37:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 May 2010 22:37:17 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273099037.92.0.862623451313.issue8633@psf.upfronthosting.co.za>


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

I didn't read the whole spec, only read quickly the invalid option.

The idead behind this issue is to be able to read a file generated by GNU tar which keeps the filename unchanged if it's not encodable to utf8. (z-pax.tar attachment was generated by GNU tar).

See also msg105085.

----------

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

From report at bugs.python.org  Thu May  6 00:43:47 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 05 May 2010 22:43:47 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273099427.74.0.652584693008.issue4265@psf.upfronthosting.co.za>


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

committed in r80830, r80831, r80833 and r80835

Thanks all !

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

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

From report at bugs.python.org  Thu May  6 00:49:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 May 2010 22:49:21 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1273099761.07.0.451325260662.issue8404@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Why do you expect dict_values to support set operations?  Dict values unlike keys are not sets, they are more like lists.  Set operations of dict_values are not supported in 3.x either.

----------
nosy: +belopolsky -Alexander.Belopolsky

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

From report at bugs.python.org  Thu May  6 00:49:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 22:49:38 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273099778.28.0.145791370513.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Perfect!  Committed in r80836 (py3k);  fixed that one test and comment in r80842 in trunk.

Alexander, do you want to tackle the 2.6 backport?

BTW, I think in most cases it's unnecessary to add Python 3.3 to the Versions field above, since there's no corresponding svn branch for 3.3.  (But it's useful if there's a task that's specifically aimed at 3.3 and not earlier versions---e.g. if something's been deprecated in 3.2 and needs to be removed in 3.3.)

----------

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

From report at bugs.python.org  Thu May  6 00:50:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 22:50:39 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273099839.1.0.158782936503.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Bah.  That's r80841, not r80842.

----------

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

From report at bugs.python.org  Thu May  6 00:51:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 22:51:07 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273099867.52.0.648895079327.issue1533@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 00:51:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 22:51:38 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273099898.67.0.79231890496.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

That should have been r80839, not r80842.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 01:35:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 May 2010 23:35:21 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273102521.82.0.657320281449.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Alexander, do you want to tackle the 2.6 backport?

I've never done a maintenance branch backport, but here is my attempt:

1. Checkout release26-maint
2. Apply 80757:80758 diff, fix rejected NEWS patch
3. Ignore 80838:80839 diff - small floats are accepted in 2.6 range.
4. Replace small float with large float in bad argument tests.  
5. make; make test; make patchcheck

I could probably use svn merge instead of svn diff + patch.  Did I miss anything important?

BTW, I've discovered "make patchcheck", does it check C files white space issues or only python files?

Mark,

I've sent you two emails off the tracker, but it looks like they did not make it through your spam filters.

----------
nosy:  -Alexander.Belopolsky
Added file: http://bugs.python.org/file17231/issue1533-release26-maint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 01:39:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 05 May 2010 23:39:21 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273102761.35.0.401712821345.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +26backport
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 01:56:34 2010
From: report at bugs.python.org (George Sakkis)
Date: Wed, 05 May 2010 23:56:34 +0000
Subject: [issue2831] Adding start to enumerate()
In-Reply-To: <1210564174.93.0.918851730075.issue2831@psf.upfronthosting.co.za>
Message-ID: <1273103794.64.0.311764089724.issue2831@psf.upfronthosting.co.za>


George Sakkis <george.sakkis at gmail.com> added the comment:

Just discovered this by chance; I would probably have noticed it earlier if the docstring had been updated. Let me know if it needs a new documentation bug ticket and I'll create one.

Pretty handy feature by the way, thanks for adding it!

----------
nosy: +gsakkis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2831>
_______________________________________

From report at bugs.python.org  Thu May  6 02:29:26 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 06 May 2010 00:29:26 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1273105766.0.0.65803444431.issue8404@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Ah, of course!  It didn't occur to me that .values() isn't necessarily a set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu May  6 02:31:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 00:31:10 +0000
Subject: [issue4265] shutil.copyfile() leaks file descriptors when disk fills
In-Reply-To: <1225916778.37.0.308517210859.issue4265@psf.upfronthosting.co.za>
Message-ID: <1273105870.9.0.187275149486.issue4265@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Wow, nice trick (shutil.open = func) :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4265>
_______________________________________

From report at bugs.python.org  Thu May  6 02:31:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 00:31:47 +0000
Subject: [issue8625] --with-pydebug builds now include -O2 by default
In-Reply-To: <1273068229.98.0.576087123255.issue8625@psf.upfronthosting.co.za>
Message-ID: <1273105907.06.0.16326111016.issue8625@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8625>
_______________________________________

From report at bugs.python.org  Thu May  6 02:46:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 00:46:48 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273106808.21.0.529667585702.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There is a couple of white-space only changes in the patch; 
> it would be good if you could reduce them.

"When two paths open to you, you should always choose the most difficult" (in french: "Quand deux chemins s'ouvrent ? nous, il faut toujours choisir le plus difficile"). I fixed posixmodule.c instead of my patch :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 02:48:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 00:48:59 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273106939.47.0.614613634503.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I notice an incompatible change: posix.environ has now a
> different element type. This is probably fine.

I don't understand, what is an "element type"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 02:54:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 May 2010 00:54:24 +0000
Subject: [issue7583] Improve explanation of tab expansion in doctests
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1273107264.17.0.204387278739.issue7583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I tried your suggestion, but it seemed to me that it made the first paragraph of that section be all about tabs, and get even farther away from its original focus, which was introducing the example.

I've attached a patch that instead moves the entire discussion of tabs to the 'fine print' section, where it arguably belongs anyway, and expands the discussion somewhat.  Feedback welcome.

----------
stage: needs patch -> patch review
type: feature request -> behavior
Added file: http://bugs.python.org/file17232/doctest-tabs-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7583>
_______________________________________

From report at bugs.python.org  Thu May  6 02:56:38 2010
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 06 May 2010 00:56:38 +0000
Subject: [issue7594] shlex refactoring
In-Reply-To: <1262074061.97.0.349318449782.issue7594@psf.upfronthosting.co.za>
Message-ID: <1273107398.74.0.906682363359.issue7594@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I tried to use this in place of shlex for parsing IMAP responses for the 'imapclient' package.  A couple of things struck me.

* The class no longer has a next() method but probably should be added for b/w compat.

* The class no longer has a 'token' attribute, which people may use to record the current token.  Sadly it isn't clear if this is a documented part of the API or not.

* Typo:
    wordchards = property(_get_wordchars, _set_wordchars)

  'wordchards' is wrong.  This implies there are no tests which set wordchars.

* I *think* the lexer is now returning an empty string token as an input source is rolled over whereas before it did not.  In effect, I *think* the old lexer would allow a single token to span sources, where this patched version does not.  Sadly I didn't confirm this is truly accurate - but tests for this behaviour would probably help.

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7594>
_______________________________________

From report at bugs.python.org  Thu May  6 03:35:47 2010
From: report at bugs.python.org (Amos Anderson)
Date: Thu, 06 May 2010 01:35:47 +0000
Subject: [issue3646] MacOS X framework install to non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1273109747.48.0.0397309771571.issue3646@psf.upfronthosting.co.za>


Amos Anderson <nitroamos at gmail.com> added the comment:

I believe I applied the patch correctly to my Python-2.6.5.tar.bz2, on my OSX 10.6.3 machine, configured with:
./configure --enable-framework=/Users/amos/triad/trunk/src/python

but "make install" now fails with this error at the end:

ln: /usr/local/bin/python2.6: Permission denied
ln: /usr/local/bin/pythonw2.6: Permission denied
ln: /usr/local/bin/idle2.6: Permission denied
ln: /usr/local/bin/pydoc2.6: Permission denied
ln: /usr/local/bin/python2.6-config: Permission denied
ln: /usr/local/bin/smtpd2.6.py: Permission denied
make[1]: *** [altinstallunixtools] Error 1
make: *** [frameworkaltinstallunixtools] Error 2


everything else appears ok...


p.s. I tried:
./configure --enable-universalsdk --with-universal-archs=intel --enable-framework=/Users/amos/triad/trunk/src/python
and got the same error.

----------
nosy: +Amos.Anderson
versions: +Python 2.6 -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17233/buildpython.script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3646>
_______________________________________

From report at bugs.python.org  Thu May  6 03:51:57 2010
From: report at bugs.python.org (Romulo A. Ceccon)
Date: Thu, 06 May 2010 01:51:57 +0000
Subject: [issue1754] WindowsError messages are not properly encoded
In-Reply-To: <1199705072.7.0.841408898872.issue1754@psf.upfronthosting.co.za>
Message-ID: <1273110717.92.0.664879782789.issue1754@psf.upfronthosting.co.za>


Romulo A. Ceccon <romuloceccon at gmail.com> added the comment:

> I think WindowsError's message should be English like other errors.
> FormatMessageW() function can take dwLanguageId parameter.
> So I think Python should pass `MAKELANGID(LANG_ENGLISH, 
> SUBLANG_ENGLISH_US)` to the parameter.

On a non-english system FormatMessageW fails with ERROR_RESOURCE_LANG_NOT_FOUND (The specified resource language ID cannot be found in the image file) when called with that parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754>
_______________________________________

From report at bugs.python.org  Thu May  6 03:54:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 06 May 2010 01:54:30 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1273110870.37.0.304494287329.issue7472@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It turns out that email5 (py3k), because it is using unicode for the payload, doesn't do the encoding to the output character set until later in the process.  Specifically, charset.body_encode no longer does the input-to-output charset conversion.  The if test in the exception clause in encoders.encode_7or8bit really is needed in email5.  So in r80855 I just port the test to py3k.  Typo fix and test also merged to 3.1 in r80856.

Hopefully that's the last we need to do on this issue.

----------
resolution: accepted -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7472>
_______________________________________

From report at bugs.python.org  Thu May  6 05:10:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 06 May 2010 03:10:47 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1273115447.31.0.296136040701.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Now that I have access to a Server 2008 R2 machine, I've verified that this fix works there.

Committed in r80857 through r80860.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Thu May  6 05:55:51 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 06 May 2010 03:55:51 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1273118151.94.0.330343975643.issue8407@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

I think this is ready for a first review.  See <http://codereview.appspot.com/1132041>.  If everyone agrees this is inappropriate for 2.7, then I'll port the changes to 3.x.  I don't expect there to be much difference in the 3.x version.

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu May  6 06:52:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 May 2010 04:52:23 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1273106939.47.0.614613634503.issue8603@psf.upfronthosting.co.za>
Message-ID: <4BE24AFE.1080609@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I notice an incompatible change: posix.environ has now a
>> different element type. This is probably fine.
> 
> I don't understand, what is an "element type"?

In a container, the contents is sometimes called "elements"; their
type is the element type. Currently, keys and values are strings;
with the change, they are bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 07:23:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 06 May 2010 05:23:59 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273123439.13.0.349859900583.issue7900@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Added file: http://bugs.python.org/file17234/os-getgroups-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu May  6 07:30:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 06 May 2010 05:30:47 +0000
Subject: [issue3646] MacOS X framework install to non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1273123847.97.0.761723388664.issue3646@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Installing a framework anywhere but a reasonably standard location doesn't work. You should try to build with "--enable-framework=$SOMEPREFIX/Library/Frameworks". Applications then get installed in "$SOMEPREFIX/Applications" and command-line tools in "$SOMEPREFIX/bin". When SOMEPREFIX is /Library or /System/Library items get installed in the usual location (but don't install into /System/Library unless you are Apple).

Supporting an arbitrary framework prefix would require a clear definition on what to do with Application bundles and command-line tools and I don't have enough of a need for that to start thinking about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3646>
_______________________________________

From report at bugs.python.org  Thu May  6 08:49:24 2010
From: report at bugs.python.org (Olivier Berten)
Date: Thu, 06 May 2010 06:49:24 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1273128564.92.0.265867660705.issue2504@psf.upfronthosting.co.za>


Olivier Berten <olivier.berten at gmail.com> added the comment:

Pleeeeeeeaaaaaaaase ;-)

----------
nosy: +olivier-berten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu May  6 08:56:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 06 May 2010 06:56:14 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1273128974.45.0.0529645154553.issue2504@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu May  6 09:11:51 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 06 May 2010 07:11:51 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1273115447.31.0.296136040701.issue7863@psf.upfronthosting.co.za>
Message-ID: <4BE26BB3.1000106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brian Curtin wrote:
> 
> Brian Curtin <curtin at acm.org> added the comment:
> 
> Now that I have access to a Server 2008 R2 machine, I've verified that this fix works there.
> 
> Committed in r80857 through r80860.

Thanks, Brian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Thu May  6 09:53:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 06 May 2010 07:53:22 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273132402.89.0.851245569222.issue8630@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

We can add those to 3.2. Not sure about 2.7 - it's already in feature freeze.

----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Thu May  6 09:59:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 May 2010 07:59:15 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273132755.65.0.194717237899.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I've never done a maintenance branch backport, but here is my attempt:
[...]

Yes, that sounds about right.  But after all that, you'll still need to modify the patch somewhat, since the requirements are different for 2.6:  floats should give a DeprecationWarning rather than a TypeError.  I think that's a straightforward change for Python/bltinmodule.c.  The trickier bit is coming up with tests that work properly---i.e., check that the appropriate warnings are produced, *and* that the the appropriate values are returned.  Look into the 'catch_warnings' function in the warnings module; (there's also 'check_warnings' in test_support, but I think that doesn't exist in 2.6).

'make patchcheck' only checks Python files and ReST files, as far as I can tell.

[I got your off-tracker emails;  will respond anon.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 10:09:27 2010
From: report at bugs.python.org (Benjamin VENELLE)
Date: Thu, 06 May 2010 08:09:27 +0000
Subject: [issue8634] [PATCH] get method for dbm interface
In-Reply-To: <1273133367.38.0.142877532423.issue8634@psf.upfronthosting.co.za>
Message-ID: <1273133367.38.0.142877532423.issue8634@psf.upfronthosting.co.za>


New submission from Benjamin VENELLE <kain94 at gmail.com>:

I'm suggesting to add the dict's 'get' method to dbm interface. So that, it would be easier to manage 'key not found' issues.

B. Venelle.

----------
components: Library (Lib)
messages: 105130
nosy: Kain94
priority: normal
severity: normal
status: open
title: [PATCH] get method for dbm interface
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8634>
_______________________________________

From report at bugs.python.org  Thu May  6 10:50:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 08:50:03 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273135803.51.0.482367025072.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Aaaah, *posix*.environ, not *os*.environ, ok. I will fix posix documentation. I didn't knew this dictionary :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 12:23:01 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 06 May 2010 10:23:01 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273141381.25.0.291897583689.issue8630@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Benjamin: Would the added parameter be a new feature or not ?

It looks like an oversight when adding the parameter to the standard codec classes, so could be viewed as a bug.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Thu May  6 12:23:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 06 May 2010 10:23:32 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273141412.17.0.146467869225.issue8630@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Andr?: Could you provide a patch ?

Thanks.

----------
assignee: benjamin.peterson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Thu May  6 12:45:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 May 2010 10:45:51 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1273142751.19.0.193772401924.issue8407@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If everyone agrees this is inappropriate for 2.7

I think the decision is up to Benjamin.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu May  6 13:25:49 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 06 May 2010 11:25:49 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273145149.6.0.0594415029935.issue8633@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Victor, you misunderstood the pax definition, but it wouldn't harm tarfile if it knew how to handle these corrupt GNU tar archives. In the meantime I filed a bug report on bug-tar at gnu.org for this.

I said in msg105085 that POSIX gives no advice on how to handle broken filename encodings, but it does in POSIX:2008. libarchive (bsdtar) uses the way that is described there. The solution is to use a field called "hdrcharset".

See http://www.opengroup.org/onlinepubs/9699919799/utilities/pax.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8633>
_______________________________________

From report at bugs.python.org  Thu May  6 13:27:30 2010
From: report at bugs.python.org (Martin)
Date: Thu, 06 May 2010 11:27:30 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1273145250.83.0.304413007231.issue8354@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

This patch has been reviewed by both Andrew and myself, it would be nice if someone made the time to land it. The test change is unlikely to break anything, and hey, that's what buildbots are for.

----------
nosy: +gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From rjvbertin at gmail.com  Thu May  6 12:28:32 2010
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E_Bertin?=)
Date: Thu, 6 May 2010 12:28:32 +0200
Subject: crash in Py_EnterRecursiveCall
Message-ID: <q2r797664591005060328l49d8fa3h81c214bd112648e6@mail.gmail.com>

Hello,

I have embedded Python into and extended it with functionality from a
graphical tool I use. One of the things it allows me to do is to
export Python objects to a simple scripting language ("ascanf"), and
call them as if they were native functions.

I have the following situation in which I get a systematic
segmentation violation in Py_EnterRecursiveCall(), in Python 2.3
(Apple's Mac OS X 10.4 system version), 2.4 2.5 and 2.6 (OS X) and on
Cygwin with 2.5 and 2.6

I enter an interactive Python 'console' from within my application,
either the one from the interact package, or the IPython shell. My
application has a callback defined for the readline routines that
calls the graphical event handler, allowing for instance
refresh/redraws to continue while working in the Python console. The
crash occurs when during such events handled through the readline
callback, I call an exported Python object. This does not appear to be
related to recursion per se, but rather to "calling a python
interpreter behind the back of the currently active
console/interpreter".

To be clearer, suppose I have some Python code

def Py_travDistCalc(a,b,c):
     ...
     return x

ascanf.ExportVariable("travDistCalc", Py_travDistCalc )

I can then issue a call
1) travDistCalc[a,b,c] from an ascanf script.
2) ascanf.Eval( 'travDistCalc[a,b,c]' ) from the Python console

Call 1) provokes a crash in Py_EnterRecursiveCall() when invoked
through the readline callback when the Python console is open, but
call 2) succeeds normally.

My workaround is to keep track of the readline callback recursion
level, and compare the current level with the level recorded when
entering a Python console before doing the PyObject_CallObject()
required in call 1) and 2) above.

I'm not sure if this is a bug in Python. It is the sort of crash
situation I'd try to avoid, though.

From report at bugs.python.org  Thu May  6 13:29:59 2010
From: report at bugs.python.org (Thomas Dybdahl Ahle)
Date: Thu, 06 May 2010 11:29:59 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1273145399.29.0.189636808535.issue7522@psf.upfronthosting.co.za>


Thomas Dybdahl Ahle <lobais at gmail.com> added the comment:

Why not just add support to the set container?
As far as I know, it is a binary search tree, so supporting random picking in O(logn) should be easy.

----------
nosy: +Thomas.Dybdahl.Ahle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Thu May  6 13:40:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 May 2010 11:40:41 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1273146041.91.0.424405950597.issue7522@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As far as I know, it is a binary search tree,

It's not:  it's based on a hash table.  It's essentially a dict with keys but no values.  An additional complication is that the hash table can be very sparsely filled, in the case of a large set that has had most of its elements deleted---there's no automatic shrinkage of the hash table in that case.  So repeated random selection until you find a filled hash table entry would be inefficient in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Thu May  6 14:06:36 2010
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_M=2E_C=2E_Campos?=)
Date: Thu, 06 May 2010 12:06:36 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273141412.17.0.146467869225.issue8630@psf.upfronthosting.co.za>
Message-ID: <p2z8fa49b8d1005060506ya6a2aa61j1d5d5492ba7fc566@mail.gmail.com>


Andr? M. C. Campos <amccampos at gmail.com> added the comment:

The parameter would not be a new feature since the codecs docs states that:
"The StreamReaderWriter allows wrapping streams which work in both
read and write modes".

The reader (StreamReader) accepts the parameter, so it's expected that
StreamReaderWriter does the same.

I'm not sure how to submit a patch.
So, I'm submitting a new codecs.py file through the issue track
interface (issue 8630).
If it's not that in that way, could you please tell me the path?
Andr?.

2010/5/6 Marc-Andre Lemburg <report at bugs.python.org>:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Andr?: Could you provide a patch ?
>
> Thanks.
>
> ----------
> assignee: benjamin.peterson ->
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8630>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Thu May  6 14:07:58 2010
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_M=2E_C=2E_Campos?=)
Date: Thu, 06 May 2010 12:07:58 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273147678.73.0.85087644689.issue8630@psf.upfronthosting.co.za>


Changes by Andr? M. C. Campos <amccampos at gmail.com>:


Added file: http://bugs.python.org/file17235/codecs.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Thu May  6 14:29:38 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 06 May 2010 12:29:38 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273148978.22.0.0135446126489.issue8633@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I am currently working on a patch to let tarfile use the hdrcharset field.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8633>
_______________________________________

From report at bugs.python.org  Thu May  6 15:03:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 13:03:51 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273151031.44.0.984713968797.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 3:
 - update posix documentation
 - improve os.environ and os.getenv() documentation: specify the type and document the encoding/error handler, add a link to environb/getenvb
 - os.environ and os.environb now check the argument types (raise a better error), on Windows and Unix. Before my patch, os.environ[b'key']=b'value' sets the variable "b'key'" to "b'value'" :-(
 - restore os.environb in TestEnviron.tearDown() (test_os)
 - fix patch on posixmodule.c indentation
 - fix a regression introduced by my patch: set PyErr_NoMemory() on error  (newstr==NULL in posixmodule.c)
 - rename keymap to encodekey

----------
Added file: http://bugs.python.org/file17236/os_environb-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 15:09:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 13:09:45 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273151385.53.0.300681621559.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh no, I forgot to remove the annotations from getenv() and getenvb() in os.py. I only removed them from the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 15:10:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 06 May 2010 13:10:43 +0000
Subject: [issue8634] get method for dbm interface
In-Reply-To: <1273133367.38.0.142877532423.issue8634@psf.upfronthosting.co.za>
Message-ID: <1273151443.52.0.194542593475.issue8634@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: [PATCH] get method for dbm interface -> get method for dbm interface
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8634>
_______________________________________

From report at bugs.python.org  Thu May  6 15:16:04 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 06 May 2010 13:16:04 +0000
Subject: [issue8635] enumerate() docstring doesn't cover optional start
	argument
In-Reply-To: <1273151764.64.0.669433681589.issue8635@psf.upfronthosting.co.za>
Message-ID: <1273151764.64.0.669433681589.issue8635@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As noted in the comments for issue 2831, the enumerate docstring doesn't cover the feature added by that patch.

----------
components: Interpreter Core
keywords: easy
messages: 105144
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: enumerate() docstring doesn't cover optional start argument
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8635>
_______________________________________

From report at bugs.python.org  Thu May  6 15:16:38 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 06 May 2010 13:16:38 +0000
Subject: [issue2831] Adding start to enumerate()
In-Reply-To: <1210564174.93.0.918851730075.issue2831@psf.upfronthosting.co.za>
Message-ID: <1273151798.67.0.617993096437.issue2831@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Created issue 8635 for the incomplete docstring

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2831>
_______________________________________

From report at bugs.python.org  Thu May  6 15:43:45 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 06 May 2010 13:43:45 +0000
Subject: [issue7583] Improve explanation of tab expansion in doctests
In-Reply-To: <1261932632.12.0.972907709846.issue7583@psf.upfronthosting.co.za>
Message-ID: <1273153425.59.0.154294755432.issue7583@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Sorry for not being able to follow up on this issue. I believe we need to expand the problem of handling tabs in doctests with use cases and expose the problem outside the issue tracker item. I still remember that at some point I had a patch somewhere that allowed to use tabs in doctests without too much explanations. Can't find it in this tracker though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7583>
_______________________________________

From report at bugs.python.org  Thu May  6 15:48:20 2010
From: report at bugs.python.org (Scott Dial)
Date: Thu, 06 May 2010 13:48:20 +0000
Subject: [issue8636] enumerate() test cases do not cover optional start
	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>


New submission from Scott Dial <scott at scottdial.com>:

The issue2831 patch test cases are not actually being run by test_enumerate and they were broken tests anyways. This patch fixes the brokenness.

----------
components: Interpreter Core, Tests
files: test_enumerate.patch
keywords: patch
messages: 105147
nosy: scott.dial
priority: normal
severity: normal
status: open
title: enumerate() test cases do not cover optional start argument
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17237/test_enumerate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8636>
_______________________________________

From report at bugs.python.org  Thu May  6 15:49:20 2010
From: report at bugs.python.org (Scott Dial)
Date: Thu, 06 May 2010 13:49:20 +0000
Subject: [issue2831] Adding start to enumerate()
In-Reply-To: <1210564174.93.0.918851730075.issue2831@psf.upfronthosting.co.za>
Message-ID: <1273153760.43.0.246941725204.issue2831@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Created issue8636 for the broken test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2831>
_______________________________________

From report at bugs.python.org  Thu May  6 15:57:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 May 2010 13:57:05 +0000
Subject: [issue8629] Fix test_ssl failures under 2.6/3.1 with OpenSSL 1.0.0
In-Reply-To: <1273076439.97.0.920291482414.issue8629@psf.upfronthosting.co.za>
Message-ID: <1273154225.31.0.726795691744.issue8629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a patch which unconditionally skips those tests in 2.6 (r80867) and 3.1 (r80868). Thanks for your advice.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8629>
_______________________________________

From amauryfa at gmail.com  Thu May  6 13:43:51 2010
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 6 May 2010 13:43:51 +0200
Subject: crash in Py_EnterRecursiveCall
In-Reply-To: <q2r797664591005060328l49d8fa3h81c214bd112648e6@mail.gmail.com>
References: <q2r797664591005060328l49d8fa3h81c214bd112648e6@mail.gmail.com>
Message-ID: <x2me27efe131005060443xb12a6472k50cbf21c485ae192@mail.gmail.com>

Hi,

2010/5/6 Ren? J.V. Bertin <rjvbertin at gmail.com>:
> Hello,
>
> I have embedded Python into and extended it with functionality from a
> graphical tool I use.

This mailing list is used for the bug tracker, and is not the place to
ask for help.
Please ask your question on the comp.lang.python newsgroup, or the o
python-list at python.org mailing list.
[maybe a hint for your issue: ensure that the current thread owns the
GIL before calling a function of the Python C API]

-- 
Amaury Forgeot d'Arc

From report at bugs.python.org  Thu May  6 17:33:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 May 2010 15:33:06 +0000
Subject: [issue8404] Set operations don't work for dictionary views
In-Reply-To: <1271294628.24.0.991589115807.issue8404@psf.upfronthosting.co.za>
Message-ID: <1273159986.01.0.99184205592.issue8404@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, this agrees with the specs in _abcoll which show KeysView and ItemsView as sets but not ValuesView.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8404>
_______________________________________

From report at bugs.python.org  Thu May  6 17:33:47 2010
From: report at bugs.python.org (Justin Bronder)
Date: Thu, 06 May 2010 15:33:47 +0000
Subject: [issue8637] [PATCH] pydoc should respect MANPAGER over PAGER.
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>


New submission from Justin Bronder <jsbronder at gentoo.org>:

Similar to man(1), pydoc should respect the environment variable MANPAGER over PAGER.  The current behavior causes issues when using a PAGER that does not support man pages.

Patch based off of trunk, r80871

----------
components: Library (Lib)
files: python-2.7-pydoc-manpager.patch
keywords: patch
messages: 105151
nosy: jsbronder
priority: normal
severity: normal
status: open
title: [PATCH] pydoc should respect MANPAGER over PAGER.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17238/python-2.7-pydoc-manpager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8637>
_______________________________________

From report at bugs.python.org  Thu May  6 17:39:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 06 May 2010 15:39:12 +0000
Subject: [issue8637] pydoc should respect MANPAGER over PAGER.
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1273160352.42.0.211349879775.issue8637@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> unit test needed
title: [PATCH] pydoc should respect MANPAGER over PAGER. -> pydoc should respect MANPAGER over PAGER.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8637>
_______________________________________

From report at bugs.python.org  Thu May  6 19:42:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 May 2010 17:42:22 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273167742.55.0.668852515404.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> the requirements are different for 2.6:  floats should give a 
> DeprecationWarning rather than a TypeError. 

I thought about it, but the comment in test_builtin.py,

	# Reject floats when it would require PyLongs to represent.                                                                                                                                          
	# (smaller floats still accepted, but deprecated)  

convinced me that raising TypeError on large floats is a feature.  I don't have a strong opinion on this issue, but I think a conservative approach is not to change current behavior in the maintenance branch unless it is clearly a bug.

I did add a test checking that "smaller floats still accepted, but deprecated."

----------
Added file: http://bugs.python.org/file17239/issue1533-release26-maint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 19:42:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 May 2010 17:42:31 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273167751.8.0.7409709713.issue1533@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17231/issue1533-release26-maint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Thu May  6 20:06:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 May 2010 18:06:11 +0000
Subject: [issue8637] pydoc should respect MANPAGER over PAGER.
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1273169171.37.0.0685172023838.issue8637@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Similar logic can be written simpler as

use_pager = os.environ.get('MANPAGER') or os.environ.get('PAGER')
if use_pager:
  ...
(yes, I think ignoring empty *PAGER is preferable to an error)

I am not sure, pydoc should respect MANPAGER.  Why not PYDOCPAGER?

In any case this is a feature request rather than a bug.

----------
nosy: +belopolsky
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8637>
_______________________________________

From report at bugs.python.org  Thu May  6 20:16:01 2010
From: report at bugs.python.org (Justin Bronder)
Date: Thu, 06 May 2010 18:16:01 +0000
Subject: [issue8637] pydoc should respect MANPAGER over PAGER.
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1273169761.29.0.160399323067.issue8637@psf.upfronthosting.co.za>


Justin Bronder <jsbronder at gentoo.org> added the comment:

I chose MANPAGER as the command line pydoc utility already clones some of the man functionality, but I'm fine with PYDOCPAGER or anything else that allows me to use pydoc without having to change PAGER first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8637>
_______________________________________

From report at bugs.python.org  Thu May  6 20:32:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 May 2010 18:32:14 +0000
Subject: [issue8636] enumerate() test cases do not cover optional start
	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1273170734.79.0.134207745646.issue8636@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch looks fine, but I wonder if regrtest.py could be taught to warn about situations like this.  Maybe run_unitest() should check that all leaf subclasses of TestCase in the module are covered.  Ideally, of course, test_main() should be made optional and tests be discovered by analyzing the test_* module.

----------
nosy: +belopolsky
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8636>
_______________________________________

From report at bugs.python.org  Thu May  6 20:53:03 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 06 May 2010 18:53:03 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273171983.16.0.513280007107.issue1285086@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I reviewed the patch and the speed test attached. 
Well, yes, the patch does achieve a certain level of speed improvement but I also saw that in cases when the quoting is really required (special characters, the current stdlib is faster). 

The speed improvement proposed is really not a convincing enough reason to replace the code of the current quote. rhettinger's comment in this issue might taken as reference to work out if there are any statistical evidence (:)?) that if the frameworks use it, would they benefit.

Few more points.

- quote is a generic function, checking for empty string, returning it  and marking it speed improvement, really is not a improvement (practically the person using the quote can avoid it too and thereby increase the speed).

- Some framework might try this , like django or zope for e.g and see if its really a worthy case in using re to check for chars to be quoted and quote only those (and see if there is any improvement).

- Might provide this as an activestate recipe and see if there any takers (again for reasons of use-case)

It is correctly a low priority one, or it can just be rejected too.

BTW, there is a feature request on quote support unicode char with patch, when that is in place, I think this request may suffer further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Thu May  6 20:53:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 06 May 2010 18:53:15 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1273171995.57.0.199995964273.issue8573@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Yes, I think it's better to remain consistent with the rest of the module which uses %s all around the place, also for backward compatibility in case someone wants to copy asyncore.py shipped with recent python versions and use it in their code using older python versions.

This practice is not so uncommon since asyncore.py received serious bug-fixing only starting from python 2.6.

Fixed in r80875 (2.7), r80876 (3.2), r80878 (2.6) and r80879 (3.1) which also includes changes to fix issue 8483.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Thu May  6 20:57:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 06 May 2010 18:57:01 +0000
Subject: [issue8483] asyncore.dispatcher's __getattr__ method produces
	confusing effects
In-Reply-To: <1271847325.07.0.737920517858.issue8483@psf.upfronthosting.co.za>
Message-ID: <1273172221.94.0.900915918679.issue8483@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed in r80875 (2.7), r80876 (3.2), r80878 (2.6) and r80879 (3.1) which also includes changes to fix issue 8573.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8483>
_______________________________________

From report at bugs.python.org  Thu May  6 21:33:39 2010
From: report at bugs.python.org (Anthony Lenton)
Date: Thu, 06 May 2010 19:33:39 +0000
Subject: [issue839159] iterators broken for weak dicts
Message-ID: <1273174419.43.0.886511885814.issue839159@psf.upfronthosting.co.za>


Anthony Lenton <anthony.lenton at canonical.com> added the comment:

Probably old news, but this also affects 2.5.4.

----------
nosy: +elachuni
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue839159>
_______________________________________

From report at bugs.python.org  Thu May  6 21:48:42 2010
From: report at bugs.python.org (Thomas Dybdahl Ahle)
Date: Thu, 06 May 2010 19:48:42 +0000
Subject: [issue7522] random.choice should accept a set as input
In-Reply-To: <1260949962.37.0.861133458828.issue7522@psf.upfronthosting.co.za>
Message-ID: <1273175322.11.0.201313006357.issue7522@psf.upfronthosting.co.za>


Thomas Dybdahl Ahle <lobais at gmail.com> added the comment:

I'm sorry. I see the problem then.
Do you know, if there are any plans of adding a fast balanced binary search tree to pythons stdlib?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7522>
_______________________________________

From report at bugs.python.org  Thu May  6 22:00:32 2010
From: report at bugs.python.org (Lucian Ursu)
Date: Thu, 06 May 2010 20:00:32 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>


New submission from Lucian Ursu <lucian_ursu at yahoo.com>:

I suggest that name mangling should not be recommended as a way of having private attributes. Instead, one underscore should be suggested as a signal that the attribute is private.
This suggestion comes after discussing with some of the helpers from #python. Basically, they said that name mangling should never be used, so it would be appropriate to remove this recommendation from the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 105161
nosy: LucianU, docs at python
priority: normal
severity: normal
status: open
title: Remove suggestion for name mangling from the tutorial
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Thu May  6 22:19:56 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 06 May 2010 20:19:56 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1273177196.0.0.0533628591449.issue8407@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Let's leave it for 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Thu May  6 22:22:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 06 May 2010 20:22:50 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1273177370.22.0.923856611103.issue3620@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Done in r80882 for ftplib and smtplib modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3620>
_______________________________________

From report at bugs.python.org  Thu May  6 22:31:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 May 2010 20:31:49 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273177909.31.0.472984679341.issue8638@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that the opinion of people helping in #python does not necessarily (or frequently) match the one of core Python developers. That said, I agree with this particular suggestion.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Thu May  6 23:07:12 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 06 May 2010 21:07:12 +0000
Subject: [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1273180032.66.0.0509988543175.issue7865@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Cool, thanks a lot B-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7865>
_______________________________________

From report at bugs.python.org  Thu May  6 23:15:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 21:15:23 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273180523.46.0.632981495877.issue8603@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17191/os_environb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 23:15:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 21:15:27 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273180527.01.0.847564579691.issue8603@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17199/os_environb-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Thu May  6 23:58:30 2010
From: report at bugs.python.org (George Sakkis)
Date: Thu, 06 May 2010 21:58:30 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>


New submission from George Sakkis <george.sakkis at gmail.com>:

Not sure if this has been brought before but how about extending  getargspec to work with callable instances, i.e. make it equivalent to getargspec(obj.__call__) ?

----------
components: Library (Lib)
messages: 105166
nosy: gsakkis
priority: normal
severity: normal
status: open
title: Allow callable objects in inspect.getargspec
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Fri May  7 00:07:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:07:17 +0000
Subject: [issue8603] Create a bytes version of os.environ and getenvb()
In-Reply-To: <1272876986.0.0.50581565866.issue8603@psf.upfronthosting.co.za>
Message-ID: <1273183637.97.0.64865609813.issue8603@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited as r80885 (py3k), blocked in 3.1 (r80886).

Thank you Martin and Marc for your great help and all your reviews ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8603>
_______________________________________

From report at bugs.python.org  Fri May  7 00:45:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:45:17 +0000
Subject: [issue8640] subprocess: add envb argument to Popen constructor
	(Python3, POSIX only)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 3.2 has now its os.environb, the bytes version of os.environ. subprocess should get a new envb argument to be able to use pure bytes environmental variables. Examples:

   subprocess.call([b'env], envb={b'PATH': b'/usr/bin'})

and

   envb = os.environb.copy()
   envb[b'PATH'] = b'/usr/bin'
   subprocess.call([b'env], envb=envb)

Specify both env and envb would raise an exception. envb should only be available on POSIX (as os.environb).

Related issues: #8513 (subprocess: support bytes program name) and #8603 (os.environb).

----------
components: Library (Lib), Unicode
messages: 105168
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess: add envb argument to Popen constructor (Python3, POSIX only)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Fri May  7 00:48:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:48:24 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273186104.07.0.711744633335.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17240/issue8513_partA.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Fri May  7 00:48:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:48:41 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273186121.91.0.923762932906.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17060/subprocess_bytes_program.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Fri May  7 00:49:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:49:48 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273186188.27.0.307742014379.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch (issue8513_partA.patch):
 - don't *decode*, only encode (str->bytes)
 - only patch os._execvpe() for POSIX

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Fri May  7 00:50:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 22:50:47 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273186247.79.0.319198007399.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If the creation of os.environb is accepted (#8603), I think that
> subprocess should also be modified to support pure bytes environ. 

I fixed #8603 and opened #8640 for subprocess and envb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Fri May  7 01:00:29 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 06 May 2010 23:00:29 +0000
Subject: [issue8640] subprocess: add envb argument to Popen constructor
	(Python3, POSIX only)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273186829.95.0.513539199718.issue8640@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Fri May  7 01:09:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:09:00 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273187340.6.0.231497802033.issue8514@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17096/os_path_fs_encode_decode-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri May  7 01:09:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:09:04 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273187344.04.0.833300897908.issue8514@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17154/issue8514.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri May  7 01:13:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:13:25 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273187605.58.0.765067146298.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New short, simple and clean path: add os.fsencode() for Unix only.

--

Don't create it for Windows to encourage the usage of unicode on Windows (and use MBCS is a bad idea). fsdecode() was a also bad idea: it's better to keep bytes unchanged on Unix, and it's now possible thanks to os.environb and os.getenvb().

----------
Added file: http://bugs.python.org/file17241/fsencode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Fri May  7 01:33:24 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 06 May 2010 23:33:24 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1273188804.04.0.218749085089.issue8591@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

bump.

Would it be more helpful if I were to submit a patch, too, or is doing so prior to guidance from the driver (Tarek) frowned upon?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Fri May  7 01:44:33 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 06 May 2010 23:44:33 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1273189473.0.0.607997064561.issue8591@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am adding Sean (jafo) who wrote this module. He'll have the best answer :)

----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Fri May  7 01:46:14 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 06 May 2010 23:46:14 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273189574.23.0.687352205981.issue8638@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Fri May  7 01:48:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 May 2010 23:48:31 +0000
Subject: [issue8640] subprocess: add envb argument to Popen constructor
	(Python3, POSIX only)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273189711.3.0.515496183958.issue8640@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why wouldn't you give byte variables in env too?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Fri May  7 01:50:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:50:29 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273189829.59.0.369855355877.issue8610@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch:
 - set encoding to ASCII on nl_langinfo(CODESET) failure
 - set encoding to ASCII if nl_langinfo(CODESET) is missing
 - document the changes

NEWS entry: "Issue #8610: Load file system codec at startup, and display a fatal error on failure. Set the file system encoding to ascii if getting the locale encoding failed, or if nl_langinfo(CODESET) function is missing."

----------
Added file: http://bugs.python.org/file17242/initfsencoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 01:50:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:50:33 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273189833.74.0.913545715962.issue8610@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17213/no_fsencoding_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 01:50:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:50:36 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273189836.66.0.844199793531.issue8610@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17214/initfsencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 01:52:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:52:21 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273189941.09.0.253283511842.issue8610@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"I think that using ASCII is a safer choice in case of errors. (...) Ouch, that was a poor choice."

Ok, you conviced me with your PYTHONFSENCODING suggestion (#8622). Can you review my last patch please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 01:57:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 May 2010 23:57:28 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1273190248.52.0.195956447733.issue8598@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It has long been true that there are test failures 
> if the testing system cannot resolve its own hostname,
> ...

I'm not sure that "localhost" must be resolved to ::1. I'm only sure for IPv4: localhost be must resolved to 127.0.0.1 in IPv4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8598>
_______________________________________

From report at bugs.python.org  Fri May  7 02:16:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 00:16:24 +0000
Subject: [issue8560] regrtest: add a minimal "progress bar"
In-Reply-To: <1272474105.27.0.516301529425.issue8560@psf.upfronthosting.co.za>
Message-ID: <1273191384.31.0.477882335988.issue8560@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Most developer are opposed to this feature, so I close this issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8560>
_______________________________________

From report at bugs.python.org  Fri May  7 02:17:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 00:17:00 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273191420.3.0.224896355505.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +Create fsencode() and fsdecode() functions in os.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Fri May  7 02:18:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 00:18:19 +0000
Subject: [issue8462] raise test_support.TestSkipped() is used outside main() /
	test_main()
In-Reply-To: <1271691287.55.0.252586227307.issue8462@psf.upfronthosting.co.za>
Message-ID: <1273191499.5.0.940272106308.issue8462@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 2.6 is in bugfix only mode, I don't think that anyone would like to spend time on this. There are more important (real) bugs.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8462>
_______________________________________

From report at bugs.python.org  Fri May  7 02:18:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 00:18:51 +0000
Subject: [issue8390] tarfile: use surrogates for undecode fields
In-Reply-To: <1271202795.91.0.928981298967.issue8390@psf.upfronthosting.co.za>
Message-ID: <1273191531.44.0.938085416349.issue8390@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8390>
_______________________________________

From report at bugs.python.org  Fri May  7 02:28:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 00:28:49 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1273192129.35.0.672372015222.issue8550@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Fri May  7 02:59:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 00:59:19 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1273193959.89.0.37470947768.issue8533@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I disabled my patch (replace_stdout function) on Windows until it gets fixed: r80905 (py3k) and r80906 (3.1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Fri May  7 06:29:00 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 07 May 2010 04:29:00 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1273206540.21.0.654982785678.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

This won't go into 2.7.0.  I will do a patch for 3.x, and wait for 2.7.0 to see if it can go into 2.7.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Fri May  7 06:29:16 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 07 May 2010 04:29:16 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1273206556.62.0.176430179779.issue8214@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

This won't go into 2.7.0.  I will do a patch for 3.x, and wait for 2.7.0 to see if it can go into 2.7.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Fri May  7 06:29:46 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 07 May 2010 04:29:46 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1273206586.45.0.253583211389.issue8214@psf.upfronthosting.co.za>


Changes by Sean Reifschneider <jafo at tummy.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Fri May  7 06:31:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 07 May 2010 04:31:56 +0000
Subject: [issue1462525] URI parsing library
Message-ID: <1273206716.5.0.542195289359.issue1462525@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Committed the tests in the r80908, r80909, r80910 and r80911.
The backward incompatible test cases, as in whose parsing requirements have changed since the previous RFC has been commented out. There were 4 abnormal scenarios and one strict parsing requirement (overridden by relaxed parsing requirement use case).

With respect to commented out tests, if we come across parsing behavior in applications relying on it, we can address it then.

Thanks Paul and others for tracking this issue.

----------
resolution: accepted -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462525>
_______________________________________

From report at bugs.python.org  Fri May  7 08:16:35 2010
From: report at bugs.python.org (Puzzlet Chung)
Date: Fri, 07 May 2010 06:16:35 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>


New submission from Puzzlet Chung <puzzlet at gmail.com>:

IDLE 3.1.2 doesn't highlight b"" syntax, instead highlights u"".

Tested with IDLE (x86) 3.1.2 and Windows XP SP2.

----------
components: IDLE
messages: 105184
nosy: puzzlet
priority: normal
severity: normal
status: open
title: IDLE 3 doesn't highlights b"", but u""
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8641>
_______________________________________

From report at bugs.python.org  Fri May  7 09:39:44 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 07 May 2010 07:39:44 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1273217984.32.0.983563179893.issue2574@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at twistedmatrix.com>:


----------
keywords: +needs review
status: open -> languishing
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2574>
_______________________________________

From report at bugs.python.org  Fri May  7 09:44:55 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 07 May 2010 07:44:55 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1273218295.57.0.204320615971.issue8354@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

I agree that this should be landed (for 2.6 and 2.7).  I think I can do it.  I made some changes to the tests, though.  It would be nice for someone to look those over and make sure the change still looks good.

I checked everything in to the siginterrupt-reset-issue8354 branch.  You can also find the diff at http://codereview.appspot.com/1134042/show

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Fri May  7 11:04:40 2010
From: report at bugs.python.org (Sreejith Madhavan)
Date: Fri, 07 May 2010 09:04:40 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273223080.28.0.0411173313959.issue8571@psf.upfronthosting.co.za>


Sreejith Madhavan <sreejithm at gmx.com> added the comment:

Attached a patch for Modules/zlibmodule.c that worked for me.  Tested with python (2.6.1 and 2.6.5) 64bit builds on Solaris (amd64 and sparc) and RHEL5.2 amd64.

----------
keywords: +patch
nosy: +Sreejith.Madhavan
Added file: http://bugs.python.org/file17243/zlibmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 11:05:34 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Fri, 07 May 2010 09:05:34 +0000
Subject: [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

At the end of description of json.loads, dump() should be load().

----------
assignee: docs at python
components: Documentation
messages: 105187
nosy: docs at python, mft
priority: normal
severity: normal
status: open
title: json.loads description
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8642>
_______________________________________

From report at bugs.python.org  Fri May  7 11:19:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 May 2010 09:19:52 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1273189941.09.0.253283511842.issue8610@psf.upfronthosting.co.za>
Message-ID: <4BE3DB33.9090904@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> "I think that using ASCII is a safer choice in case of errors. (...) Ouch, that was a poor choice."
> 
> Ok, you conviced me with your PYTHONFSENCODING suggestion (#8622). Can you review my last patch please?

I don't think we can change the fallback encoding in 3.2. But you
can start a discussion on python-dev, of course.

The number of Python 3.x users is still small, so perhaps it's still
possible to revert the choice and to use a safer default, which then
results in encoding errors that the user can see in form of tracebacks
rather than just by having actively checking the directory listing
for strange symbols.

Some comments on the patch:

+		fprintf(stderr,
+			"Unable to get the locale encoding: "
+			"fallback to utf-8\n");

This would have to read "... to ASCII"

+		Py_FileSystemDefaultEncoding = "ascii";

+	codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
+	if (!codec) {
+		Py_FatalError(
+		    "Py_Initialize: unable to load the file system codec");

It's better to use the same approach as above for this situation
as well.

Fatal errors are just not user friendly and will likely cause
bad vibes towards Python3.

E.g.

		fprintf(stderr,
			"Unknown locale encoding: "
			"fallback to ASCII\n");

You also need to change this line in pythonrun.c:

        /* reset file system default encoding */
        if (!Py_HasFileSystemDefaultEncoding) {
                free((char*)Py_FileSystemDefaultEncoding);
                Py_FileSystemDefaultEncoding = NULL;
        }

I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
is. If we define a default for the file system encoding,
then why do we bother whether there is one ?

In any case, initfsencoding() would always have to set that
flag to 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 12:54:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 10:54:07 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <4BE3DB33.9090904@egenix.com>
Message-ID: <201005071253.57122.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 07 mai 2010 11:19:52, vous avez ?crit :
> > Ok, you conviced me with your PYTHONFSENCODING suggestion (#8622). Can
> > you review my last patch please?
> 
> I don't think we can change the fallback encoding in 3.2. But you
> can start a discussion on python-dev, of course.

Ok, I will ask on python-dev.

> +		fprintf(stderr,
> +			"Unable to get the locale encoding: "
> +			"fallback to utf-8\n");
> 
> This would have to read "... to ASCII"

Fixed.

> 
> +		Py_FileSystemDefaultEncoding = "ascii";
> 
> +	codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
> +	if (!codec) {
> +		Py_FatalError(
> +		    "Py_Initialize: unable to load the file system codec");
> 
> It's better to use the same approach as above for this situation
> as well.

I choosed to display a fatal error here to give a more revelant error message 
to the user. Without the check, _PyCodec_Lookup() will fail anyway, but later 
in a random function :-/

The fatal error only occurs in critical situations: no more memory, import 
machinery completly broken (eg. #8611), etc. In this case, fallback to ASCII 
doesn't help, it will also raise somewhere later.

About nl_langinfo(CODESET): get_codeset() does already reject unknown 
encoding. So this call is only done on known encoding names.

> You also need to change this line in pythonrun.c:
> 
>         /* reset file system default encoding */
>         if (!Py_HasFileSystemDefaultEncoding) {
>                 free((char*)Py_FileSystemDefaultEncoding);
>                 Py_FileSystemDefaultEncoding = NULL;
>         }

Fixed. This test only match if get_codeset() is used: I choosed to set the 
encoding to ASCII with Py_HasFileSystemDefaultEncoding=0.

> I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
> is.

Its name doesn't help. It's just a flag to tell if free() should be called or 
not... (see _Py_SetFileSystemEncoding()).

> In any case, initfsencoding() would always have to set that
> flag to 1.

initfsencoding() is a static function and it's only called by 
Py_InitializeEx(). Can Py_InitializeEx() be called multiple times?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 12:54:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 10:54:22 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273229662.95.0.129512491911.issue8610@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17244/initfsencoding-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 12:54:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 10:54:32 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273229672.67.0.00499457777696.issue8610@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17242/initfsencoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 13:11:18 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Fri, 07 May 2010 11:11:18 +0000
Subject: [issue8643] incorrect timedelta yielded by two on-the-fly nows
In-Reply-To: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>
Message-ID: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>


New submission from Michal Bo?o? <michal.bozon at gmail.com>:

now() - now() from datetime.datetime produces not-nearly-zero timedelta:

>>> import datetime
>>> (datetime.datetime.now() - datetime.datetime.now()).seconds
86399

(i can't in the moment figure out why this is happening, sice the datetime library is written in C)

----------
components: Library (Lib)
messages: 105190
nosy: mykhal
priority: normal
severity: normal
status: open
title: incorrect timedelta yielded by two on-the-fly nows
type: behavior
versions: Python 2.5, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8643>
_______________________________________

From report at bugs.python.org  Fri May  7 13:13:41 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 07 May 2010 11:13:41 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273230821.32.0.414160027863.issue8638@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Maybe the wording should be changed, but name mangling serves a useful
purpose.  There are two definitions of "private" which seem to be a
bit conflated in this section:

* "private" as in, "this name is not part of the public API - use it
  at your own risk".

* "private" as in, "I don't want someone to accidentally stomp on this
  attribute name when subclassing this class".

I think it is valuable to mention both of these conventions in the
tutorial for a couple reasons:

* the tutorial is meant for people new to Python but with experience
  in other programming languages

* the distinction between _a and __a is a bit subtle and not obviously
  similar to privacy features present in other languages.

I work with a lot of C++ programmers who also write some Python
(sometimes a lot of Python).  It's clear at times that the distinction
hasn't always sunk in.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Fri May  7 13:20:35 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Fri, 07 May 2010 11:20:35 +0000
Subject: [issue8643] incorrect timedelta yielded by two on-the-fly nows
	subtraction
In-Reply-To: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>
Message-ID: <1273231235.1.0.294566143173.issue8643@psf.upfronthosting.co.za>


Changes by Michal Bo?o? <michal.bozon at gmail.com>:


----------
title: incorrect timedelta yielded by two on-the-fly nows -> incorrect timedelta yielded by two on-the-fly nows subtraction

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8643>
_______________________________________

From report at bugs.python.org  Fri May  7 13:33:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 11:33:26 +0000
Subject: [issue8643] incorrect timedelta yielded by two on-the-fly nows
	subtraction
In-Reply-To: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>
Message-ID: <1273232006.98.0.593760712838.issue8643@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is correct behaviour.  Note that .seconds is only one of the three attributes that contribute to the value of a timedelta:  the others are .microseconds and .days.  A timedelta is normalised in such a way that td.seconds and td.microseconds are always nonnegative;  this means that td.days will be strictly negative for negative timedeltas.  In your case the timedelta will have a .days attribute of -1, and the total time represented (e.g., in seconds, 86400.0 * td.days + td.seconds + 0.000001 * td.microseconds) will be small and negative.

Here's what I get on my system (in the py3k branch):

Python 3.2a0 (py3k:80840:80842, May  7 2010, 12:29:35) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> td = datetime.datetime.now() - datetime.datetime.now()
>>> td.microseconds, td.seconds, td.days
(998977, 86399, -1)
>>> print(td)
-1 day, 23:59:59.998977
>>> 1e-6 * td.microseconds + td.seconds + 86400 * td.days
-0.0010230000043520704
>>> td.total_seconds() # new in Python 2.7, 3.2
-0.0010230000043520704

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8643>
_______________________________________

From report at bugs.python.org  Fri May  7 13:45:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 11:45:06 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273232706.77.0.230565784867.issue8571@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Confirmed. It even segfaults under 3.x.

----------
nosy: +pitrou
priority: normal -> high
stage:  -> patch review
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 13:45:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 11:45:24 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273232724.37.0.784632797124.issue8571@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 13:58:52 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Fri, 07 May 2010 11:58:52 +0000
Subject: [issue8643] incorrect timedelta yielded by two on-the-fly nows
	subtraction
In-Reply-To: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>
Message-ID: <1273233532.68.0.106381755789.issue8643@psf.upfronthosting.co.za>


Michal Bo?o? <michal.bozon at gmail.com> added the comment:

ok, my fault, i should have tried

>>> (abs(datetime.datetime.now() - datetime.datetime.now())).seconds
0

sorry :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8643>
_______________________________________

From report at bugs.python.org  Fri May  7 14:09:10 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 May 2010 12:09:10 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <201005071253.57122.victor.stinner@haypocalc.com>
Message-ID: <4BE402E3.3070409@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
>> +	codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
>> +	if (!codec) {
>> +		Py_FatalError(
>> +		    "Py_Initialize: unable to load the file system codec");
>>
>> It's better to use the same approach as above for this situation
>> as well.
> 
> I choosed to display a fatal error here to give a more revelant error message 
> to the user. Without the check, _PyCodec_Lookup() will fail anyway, but later 
> in a random function :-/
> 
> The fatal error only occurs in critical situations: no more memory, import 
> machinery completly broken (eg. #8611), etc. In this case, fallback to ASCII 
> doesn't help, it will also raise somewhere later.
> 
> About nl_langinfo(CODESET): get_codeset() does already reject unknown 
> encoding. So this call is only done on known encoding names.

Ok, please add a comment to that part explaining why it can only
fail as result of some other serious error and not because
the Py_FileSystemDefaultEncoding was not found to be supported
by Python.

>> I'm not sure what the purpose of Py_HasFileSystemDefaultEncoding
>> is.
> 
> Its name doesn't help. It's just a flag to tell if free() should be called or 
> not... (see _Py_SetFileSystemEncoding()).

Interesting... I would associate a completely different meaning
with it.

Scratch my comment on that flag then.

>> In any case, initfsencoding() would always have to set that
>> flag to 1.
> 
> initfsencoding() is a static function and it's only called by 
> Py_InitializeEx(). Can Py_InitializeEx() be called multiple times?

Well, it shouldn't be called multiple times, but then you never
know how embedded Python interpreters are used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 14:15:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 12:15:44 +0000
Subject: [issue8643] incorrect timedelta yielded by two on-the-fly nows
	subtraction
In-Reply-To: <1273230678.16.0.688887441579.issue8643@psf.upfronthosting.co.za>
Message-ID: <1273234544.23.0.485841930399.issue8643@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  My example did make me realize that the total_seconds() method isn't as accurate as it could be.  I'll open another issue for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8643>
_______________________________________

From report at bugs.python.org  Fri May  7 14:24:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 12:24:55 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I just noticed (while responding to issue 8643) that timedelta.total_seconds() has some accuracy problems, especially for negative timedeltas:

Python 3.2a0 (py3k:80840:80842, May  7 2010, 12:29:35) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import timedelta
>>> td = timedelta(microseconds = -123)
>>> td.total_seconds() # expect -0.000123
-0.0001230000052601099

This could be easily fixed by using integer arithmetic internally instead of float arithmetic:

>>> 1e-6 * td.microseconds + td.seconds + 86400 * td.days
-0.0001230000052601099
>>> (td.microseconds + 1000000 * (td.seconds + 86400 * td.days)) / 1000000
-0.000123

This works especially nicely in combination with the new float repr and the improved accuracy of true division in 2.7 / 3.2, to give a total_seconds() whose repr is free of noise digits.  (Well, for small timedeltas, anyway.)

Since total_seconds is new in 2.7 and 3.2, I think it would be good to fix this before the 2.7 release.

----------
components: Extension Modules
messages: 105197
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: timedelta.total_seconds needlessly inaccurate, especially for negative timedeltas
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Fri May  7 14:30:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 12:30:04 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273235404.78.0.932852515796.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

P.S.  This change would also make total_seconds() consistent with division by timedelta(seconds=1):

>>> td / timedelta(seconds=1)
-0.000123

In fact, this might even be a good way to re-implement total_seconds internally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Fri May  7 15:12:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 13:12:51 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273237971.94.0.722569106495.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, okay---that makes some sense;  I'm happy to leave floats as they are (i.e., DeprecationWarning for small floats; TypeError for larger floats) and just fix use of __int__ for non-floats.

I'll look at the patch.

----------
assignee: belopolsky -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Fri May  7 15:26:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 13:26:32 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1273238792.65.0.00478053943333.issue1533@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The backport looks fine.  Applied in r80917.  Thanks, Alexander.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
_______________________________________

From report at bugs.python.org  Fri May  7 16:05:47 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 May 2010 14:05:47 +0000
Subject: [issue8388] None shouldn't be passed to traceback.format_exception
In-Reply-To: <1271199714.1.0.812266738214.issue8388@psf.upfronthosting.co.za>
Message-ID: <1273241147.55.0.27251366459.issue8388@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Now fixed.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8388>
_______________________________________

From report at bugs.python.org  Fri May  7 16:08:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 May 2010 14:08:32 +0000
Subject: [issue8454] unittest Module Problem with different Kinds of Invocation
In-Reply-To: <1271676431.2.0.515537507325.issue8454@psf.upfronthosting.co.za>
Message-ID: <1273241312.49.0.836045120117.issue8454@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8454>
_______________________________________

From report at bugs.python.org  Fri May  7 16:38:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 14:38:46 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273243126.49.0.994264259317.issue8571@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 17:09:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 May 2010 15:09:31 +0000
Subject: [issue8388] None shouldn't be passed to traceback.format_exception
In-Reply-To: <1271199714.1.0.812266738214.issue8388@psf.upfronthosting.co.za>
Message-ID: <1273244971.13.0.696641434096.issue8388@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Revision 80708 and revision 80709.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8388>
_______________________________________

From report at bugs.python.org  Fri May  7 17:55:35 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 15:55:35 +0000
Subject: [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

PyUnicode_AsEncodedObject is undocumented.  It has the same signature as PyUnicode_AsEncodedString, although they do slightly different things based on a brief source code inspection (I'm not clear on what that difference is though).

----------
assignee: docs at python
components: Documentation
messages: 105203
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_AsEncodedObject is undocumented
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8645>
_______________________________________

From report at bugs.python.org  Fri May  7 17:55:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 15:55:59 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273247759.82.0.945847578057.issue8571@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch fixing the issue, and a similar one in compressobj.compress(). It also adds tests which are only enabled with the bigmem option.

----------
Added file: http://bugs.python.org/file17245/zlibbigbuf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 17:59:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 15:59:05 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

PyUnicode_EncodeDecimal is undocumented (although it's referenced in passing in the documentation for PyLong_FromUnicode).  There's a lengthy comment in unicodeobject.h describing PyUnicode_EncodeDecimal, which could be converted more or less directly into documentation.

----------
assignee: docs at python
components: Documentation
messages: 105205
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_EncodeDecimal is undocumented
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Fri May  7 18:07:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:07:19 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Here's the relevant signature:

/* Get the maximum ordinal for a Unicode character. */
PyAPI_FUNC(Py_UNICODE) PyUnicode_GetMax(void);

----------
assignee: docs at python
components: Documentation
messages: 105206
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_GetMax is undocumented
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Fri May  7 18:10:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:10:36 +0000
Subject: [issue8648] The UTF-7 codec functions are undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The UTF-7 codec functions are undocumented:

PyUnicode_DecodeUTF7Stateful
PyUnicode_DecodeUTF7
PyUnicode_EncodeUTF7

----------
assignee: docs at python
components: Documentation
messages: 105207
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: The UTF-7 codec functions are undocumented
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8648>
_______________________________________

From report at bugs.python.org  Fri May  7 18:26:30 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 07 May 2010 16:26:30 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1273247759.82.0.945847578057.issue8571@psf.upfronthosting.co.za>
Message-ID: <x2j52dc1c821005070926ifc8d463ehfe5651b209d3263c@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

in the unittests there is some use of 'compress' and 'decompress'
mixed with 'zlib.decompress'.  which one is right (i'm only looking at
the diff so i can't see if they were imported from zlib or if the
zlib. is required at the moment).

otherwise, provided the new bigmem tests pass.  looks good to me.
commit and backport through to 2.6.

On Fri, May 7, 2010 at 8:56 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Here is a patch fixing the issue, and a similar one in compressobj.compress(). It also adds tests which are only enabled with the bigmem option.
>
> ----------
> Added file: http://bugs.python.org/file17245/zlibbigbuf.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8571>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 18:36:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 May 2010 16:36:04 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273250164.38.0.966149067498.issue8644@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch for py3k branch.  I am +1 for backporting to 2.7 and I avoided relying on py3k timedelta/timedelta in the patch.  The tests  and docs will need to be modified for the backport.

Technically speaking, this is a change in documented behavior for 2.7 because according to current docs, td.total_seconds() is equivalent to ``td.microseconds / 1000000 + td.seconds + td.days * 24 * 3600``.  Therefore I would appreciate if reviewer made a decision on backport.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17246/issue8644-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Fri May  7 18:36:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 16:36:24 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <x2j52dc1c821005070926ifc8d463ehfe5651b209d3263c@mail.gmail.com>
Message-ID: <1273250329.4188.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> in the unittests there is some use of 'compress' and 'decompress'
> mixed with 'zlib.decompress'.  which one is right

When testing the decompressor, data needs to be prepared first
(compressed). I didn't bother creating a compressor object in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 18:39:28 2010
From: report at bugs.python.org (Denis Dmitriev)
Date: Fri, 07 May 2010 16:39:28 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273250368.64.0.839378980504.issue8571@psf.upfronthosting.co.za>


Denis Dmitriev <dmitriev at deshaw.com> added the comment:

Is there a reason to keep inplen and max_length ints instead of making them Py_ssize_t too? I'm a little worried that keeping them ints will cause a similar problem further down the line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 18:42:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 16:42:15 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273250535.33.0.600141098024.issue8610@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 4: I forgot #include <langinfo.h> in bltinmodule.c.

----------
Added file: http://bugs.python.org/file17247/initfsencoding-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 18:42:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 16:42:20 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273250540.94.0.390109457204.issue8610@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17244/initfsencoding-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Fri May  7 18:46:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 16:46:41 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1273250368.64.0.839378980504.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273250946.4188.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is there a reason to keep inplen and max_length ints instead of making
> them Py_ssize_t too?

zlibmodule.c isn't 64-bit clean internally. Actually, the zlib itself
uses uInt in its z_stream structure. This should be the target of a
separate issue, and seems it will require more work than simply changing
the type of a variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 18:48:41 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:48:41 +0000
Subject: [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Python provides several functions for manipulating raw Py_UNICODE strings, but they aren't documented.  Below are their signatures.

PyAPI_FUNC(size_t) Py_UNICODE_strlen(const Py_UNICODE *u);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strcpy(
    Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strncpy(
    Py_UNICODE *s1, const Py_UNICODE *s2, size_t n);

PyAPI_FUNC(int) Py_UNICODE_strcmp(
    const Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strchr(
    const Py_UNICODE *s, Py_UNICODE c
    );

----------
assignee: docs at python
components: Documentation
messages: 105214
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_UNICODE_* functions are undocumented
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8649>
_______________________________________

From report at bugs.python.org  Fri May  7 18:58:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 May 2010 16:58:55 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1273251535.05.0.368948523968.issue7900@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Fri May  7 19:09:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:09:53 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273252193.38.0.253591890419.issue8571@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r80926 (trunk), r80927 (2.6), r80928 (py3k) and r80929 (3.1). Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 19:12:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:12:05 +0000
Subject: [issue8571] zlib causes a SystemError when decompressing a chunk >1GB
In-Reply-To: <1272555357.11.0.654496142988.issue8571@psf.upfronthosting.co.za>
Message-ID: <1273252325.94.0.0742426389271.issue8571@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8571>
_______________________________________

From report at bugs.python.org  Fri May  7 19:21:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:21:02 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, and uses lots of "int" variables for length values internally.
Besides, the zlib itself uses "uInt" and "uLong" variables in its z_stream structure (rather than something guaranteed to be at least the width of a pointer).

On large input data, this will conspire to produce bogus results or crashes. For example:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

----------
components: Extension Modules
messages: 105216
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: zlibmodule.c isn't 64-bit clean
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/issue8650>
_______________________________________

From report at bugs.python.org  Fri May  7 19:24:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:24:38 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1273253078.36.0.725109498649.issue8650@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Fri May  7 19:24:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 17:24:56 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

When PY_SSIZE_T isn't defined and a format such as "s#" receives an object whose length fits in a Py_ssize_t but not in an int, the buffer length is silently truncated:

>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

(from issue8650)

----------
components: Interpreter Core
messages: 105217
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "s#" and friends can silently truncate buffer length
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/issue8651>
_______________________________________

From report at bugs.python.org  Fri May  7 19:25:34 2010
From: report at bugs.python.org (Marien Zwart)
Date: Fri, 07 May 2010 17:25:34 +0000
Subject: [issue8652] Minor improvements to the "Handling Exceptions" part of
	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>


New submission from Marien Zwart <m_zwart at 123mail.org>:

Based on questions asked on freenode's #python by people reading the tutorial I would like to suggest two improvements to http://docs.python.org/tutorial/errors.html#handling-exceptions :

- Mention the older "except SomeException, e:" syntax too, not just "except SomeException as e:". I have had people ask me to help them upgrade to a newer python because they thought their version of python did not support catching exception instances (their distro python being 2.5). A big fat warning that they're reading the Python 2.6 tutorial (with links to older tutorials) may also work.

- Mention "except IOError as e" before mentioning "except IOError as (errno, strerror):". The latter is an advanced and relatively unusual trick, combining regular exception catching and unpacking. Those two concepts need to be explained before the combination is. I have had people ask me how to do "except KeyError as (key, insert_something_here):" because they thought they *always* needed those parens there.

(perhaps just not mentioning unpacking here at all, using "except IOError as e:" and then using e.errno would make more sense, especially since "except IOError as (errno, strerror):" is a SyntaxError in python 3 and up (because of the unpacking) and python 2.5.x and down (because of the "as")...)

I can try to write a patch to the documentation if you like.

----------
assignee: docs at python
components: Documentation
messages: 105218
nosy: docs at python, marienz
priority: normal
severity: normal
status: open
title: Minor improvements to the "Handling Exceptions" part of the tutorial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8652>
_______________________________________

From report at bugs.python.org  Fri May  7 20:03:27 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 May 2010 18:03:27 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273255407.12.0.210459161012.issue8084@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Christian hasn't been around for a while, and I'd like to release the next beta on time. Thus, I think Tarek's or my review will be sufficent. The idea seems fine to me.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Fri May  7 20:16:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 May 2010 18:16:52 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1273256212.3.0.62315985013.issue8547@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 80932. Still needs documenting, so leaving open for the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Fri May  7 20:39:02 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Fri, 07 May 2010 18:39:02 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

The docstrings for these functions don't explain the 'scheme' parameter.  Even renaming it to default_scheme would help.

----------
assignee: docs at python
components: Documentation
messages: 105221
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: urlparse.urlparse/urlsplit doc missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Fri May  7 21:02:45 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 19:02:45 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Currently, Python can be built with an internal Unicode representation of UCS2 or UCS4.  To prevent extension modules compiled with the wrong Unicode representation from linking, unicodeobject.h #defines many of the Unicode functions.  For example, PyUnicode_FromString becomes either PyUnicodeUCS2_FromString or PyUnicodeUCS4_FromString.

Consequently, if one installs a binary egg (e.g., with easy_install), there's a good chance one will get an error such as the following when trying to use it:

        undefined symbol: PyUnicodeUCS2_FromString

In Python 2, only some extension modules were stung by this problem.  For Python 3, virtually every extension type will need to call a PyUnicode_* function, since __repr__ must return a Unicode object.  It's basically fruitless to upload a binary egg for Python 3 to PyPi, since it will generate link errors for a large fraction of downloaders (I discovered this the hard way).

Right now, nearly all the functions in unicodeobject.h are wrapped.  Several functions are not.  Many of the unwrapped functions also have no documentation, so I'm guessing they are newer functions that were not wrapped when they were added.

Most extensions treat PyUnicodeObjects as opaque and do not care if the internal representation is UCS2 or UCS4.  We can improve ABI compatibility by only wrapping functions where the representation matters from the caller's point of view.

For example, PyUnicode_FromUnicode creates a Unicode object from an array of Py_UNICODE objects.  It will interpret the data differently on UCS2 vs UCS4, so the function should be wrapped.

On the other hand, PyUnicode_FromString creates a Unicode object from a char *.  The caller can treat the returned object as opaque, so the function should not be wrapped.

The attached patch implements that rule.  It unwraps 64 opaque functions that were previously wrapped, and wraps 11 non-opaque functions that were previously unwrapped.  "make test" works with both UCS2 and UCS4 builds.

I previously brought this issue up on python-ideas, see:
http://mail.python.org/pipermail/python-ideas/2009-November/006543.html

Here's a summary of that discussion:

Zooko Wilcox-O'Hearn pointed out that my proposal is complimentary to his proposal to standardize on UCS4, to reduce the risk of extension modules built with a mismatched encoding.

Stefan Behnel pointed out that easy_install should allow eggs to specify the encoding they require.  PJE's proposed implementation of that feature (http://bit.ly/1bO62) would allow eggs to specify UCS2, UCS4, or "Don't Care".  My proposal greatly increases the number of eggs that could label themselves "Don't Care", reducing maintenance work for package maintainers.  In other words, they are complimentary fixes.

Guido liked the idea but expressed concern about the possibility of extension modules that link successfully, but later crash because they actually do depend on the UCS2/UCS4 distinction.

With my current patch, there are still two ways for that to happen:

1) The extension uses only opaque functions, but casts the returned PyObject * to PyUnicodeObject * and accesses the str member, or

2) The extension uses only opaque functions, but uses the PyUnicode_AS_UNICODE or PyUnicode_AS_DATA macros.

Most packages that poke into the internals of PyUnicodeObject also call non-opaque functions.  Consequently, they will still generate a linker error if the encoding is mismatched, as desired.

I'm trying to come up with a way to 100% guarantee that any extension poking into the internals will generate a linker error if the encoding is mismatched, even if they don't call any non-opaque functions.  I'll post about that in a separate comment to this bug.

----------
assignee: stutzbach
components: Interpreter Core, Unicode
messages: 105222
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve ABI compatibility between UCS2 and UCS4 builds
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Fri May  7 21:04:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 19:04:05 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273259045.21.0.743725415534.issue8654@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17248/unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Fri May  7 21:21:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 19:21:48 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1273260108.98.0.445529929506.issue1759169@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A question about the patch: in configure.in, after "if test $define_xopen_source = yes" (lines 395 and following), there's a bunch of Solaris-specific stuff. Shouldn't it be removed, given that _XOPEN_SOURCE isn't defined anymore under Solaris?

----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Fri May  7 21:24:10 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 19:24:10 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273260250.9.0.405940490001.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Forcing the compile-time and link-time encodings to match is tricky.  The goal is:

- Allow Unicode-agnostic modules to link, regardless of unicode settings
- Cause a link failure if the unicode settings are mismatched for a module that pokes into PyUnicodeObject

All of the solutions I've come up with have trade-offs.  Here is one approach:

Expose PyUnicodeObject if and only if the extension #defines a special flag (PY_EXPOSE_UNICODE_OBJECT?) before including Python.h.

If an extension does NOT define the flag, then PyUnicodeObject will not be defined nor the accessor macros for accessing its fields.  All of the opaque and non-opaque functions are still defined; the module just can't poke directly into PyUnicodeObject.  Linking will succeed as long as the module avoids non-opaque functions.

If the flag IS defined, then PyUnicodeObject will be defined along with the accessor macros.  The unicodeobject.h header will also arrange to require an appropriate symbol so that linking will succeed only if the module is compiled with the same Unicode settings as Python.

The upside of this approach is that it works: Unicode-agnostic modules will link and all others will not.

The drawback is a few extension modules will need to have a #define before including Python.h.  Only modules that poke into PyUnicodeObject will be impacted.  No change will be required for modules that depend on the Unicode setting yet stick to functions (opaque or not).

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Fri May  7 21:28:57 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 19:28:57 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273260537.3.0.470120020218.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Adding people to the Nosy List who participated in the original thread on python-ideas, several months ago.  Hope you don't mind. :-)

----------
nosy: +gvanrossum, scoder, zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Fri May  7 22:36:13 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 07 May 2010 20:36:13 +0000
Subject: [issue7735] python creates IPv6 DNS requests even when built with
	--disable-ipv6
In-Reply-To: <1263855099.58.0.477702556639.issue7735@psf.upfronthosting.co.za>
Message-ID: <1273264573.04.0.55820263768.issue7735@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7735>
_______________________________________

From report at bugs.python.org  Fri May  7 22:41:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 07 May 2010 20:41:07 +0000
Subject: [issue7735] python creates IPv6 DNS requests even when built with
	--disable-ipv6
In-Reply-To: <1263855099.58.0.477702556639.issue7735@psf.upfronthosting.co.za>
Message-ID: <1273264867.8.0.485279039298.issue7735@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7735>
_______________________________________

From report at bugs.python.org  Fri May  7 22:46:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 May 2010 20:46:25 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1273265185.46.0.441168895924.issue8547@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Reverted this in r80939. See http://python.org/dev/buildbot/stable/builders/x86%20XP-4%20trunk/builds/3553/steps/test/logs/stdio

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Fri May  7 22:49:54 2010
From: report at bugs.python.org (Westly Ward)
Date: Fri, 07 May 2010 20:49:54 +0000
Subject: [issue8655] Problem with getpeercert in the ssl module when
	retrieving client side certs
In-Reply-To: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>
Message-ID: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>


New submission from Westly Ward <sonicrules1234 at gmail.com>:

I originally had this problem when writing my IRCd, but then tested it in a basic script.  The problem is that getpeercert() is always returning None when executed on the server side, even when the client is using an ssl cert.  I have included an example in the attachment.  Just run sslserver.py in one terminal window, and then run sslclient.py in the other.  I also included the two fresh ssl certs and keys I used.  In client.txt and server.txt I put the commands I used to generate the ssl certs and keys.

----------
components: Library (Lib)
files: ssltest.tar.gz
messages: 105227
nosy: Westly.Ward
priority: normal
severity: normal
status: open
title: Problem with getpeercert in the ssl module when retrieving client side certs
versions: Python 2.6
Added file: http://bugs.python.org/file17249/ssltest.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8655>
_______________________________________

From report at bugs.python.org  Fri May  7 22:58:25 2010
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Fri, 07 May 2010 20:58:25 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1273265905.66.0.817416978761.issue4171@psf.upfronthosting.co.za>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

Well, I'm sorry to bring this up again, but the problem persists
with Python 3.1.2 (x86, Windows XP). The difference with the
test script behaviour is that now it doesn't break every time.
Perhaps this is the reason I said the problem was gone.
In fact, now that I run the aforementioned script I may get

worked so far
but not here it didn't

and some other time I may get

worked so far
Traceback (most recent call last):
  File "test.py", line 23, in <module>
    test_handshake(address, False)
  File "test.py", line 17, in test_handshake
    ssl.do_handshake()
  File "C:\Python31\lib\ssl.py", line 327, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

and the outcome is unpredictable. It may work many times in a row
and it may break many times in a row.

If this is of any relevance, I've had pywin32-2.14 installed since.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Fri May  7 23:06:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 21:06:14 +0000
Subject: [issue8655] Problem with getpeercert in the ssl module when
	retrieving client side certs
In-Reply-To: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>
Message-ID: <1273266374.15.0.760130142372.issue8655@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You must use either ssl.CERT_OPTIONAL or ssl.CERT_REQUIRED if you want to retrieve the client certificate. I admit this makes the getpeercert() API a bit strange, and I'm not sure why the original decision was made.

Can you confirm this fixes your issue?

----------
nosy: +janssen, pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8655>
_______________________________________

From report at bugs.python.org  Fri May  7 23:24:02 2010
From: report at bugs.python.org (Westly Ward)
Date: Fri, 07 May 2010 21:24:02 +0000
Subject: [issue8655] Problem with getpeercert in the ssl module when
	retrieving client side certs
In-Reply-To: <1273265394.09.0.646660549737.issue8655@psf.upfronthosting.co.za>
Message-ID: <1273267442.54.0.446798585717.issue8655@psf.upfronthosting.co.za>


Westly Ward <sonicrules1234 at gmail.com> added the comment:

When I use the argument to make certs optional, it gave me an error saying it need the ca certs, so I downloaded them and specified to use them, and now I am getting errors from ssl.c

Here's the error on the server side:

westly at westly-desktop ~/Desktop/ssltest $ python sslserver.py 
Traceback (most recent call last):
  File "sslserver.py", line 8, in <module>
    conn, addr, = a.accept()
  File "/usr/lib/python2.6/ssl.py", line 326, in accept
    suppress_ragged_eofs=self.suppress_ragged_eofs),
  File "/usr/lib/python2.6/ssl.py", line 118, in __init__
    self.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 293, in do_handshake
    self._sslobj.do_handshake()
SSLError: [Errno 1] _ssl.c:480: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned

Here's the error on the client side:

westly at westly-desktop ~/Desktop/ssltest $ python sslclient.py 
Traceback (most recent call last):
  File "sslclient.py", line 4, in <module>
    a.connect(("127.0.0.1", 112233))
  File "/usr/lib/python2.6/ssl.py", line 309, in connect
    self.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 293, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:480: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

I got the ca certs from http://www.positivessl.com/ssl-certificate-support/cert_installation/UTN-USERFirst-Hardware.crt which is from a link the the ssl module docs.

I have attached the modified scripts.

----------
status: pending -> open
Added file: http://bugs.python.org/file17250/ssltest.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8655>
_______________________________________

From report at bugs.python.org  Fri May  7 23:24:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 21:24:38 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1273267478.79.0.950370108632.issue4171@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Are you able to compile a fresh checkout of either the py3k or release3.1-maint branch? A bunch of fixes have been committed recently, some of which may (or even should) address your issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Fri May  7 23:33:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 21:33:18 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273267998.95.0.353205378693.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch!  Comments, in increasing order of fussiness:

(1) there should be a Py_DECREF(total_microseconds) in the case that the "PyLong_FromLong(1000000L)" call fails

(2) in the docstring, replace 'loose' by 'lose'

(3) also in the docstring, I suggest replacing "280 years" by "270 years":   "td == timedelta(seconds = td.total_seconds())" starts failing at 2**33 seconds (around 272.2 Julian years) rather than 2**53 microseconds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Fri May  7 23:38:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 May 2010 21:38:29 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273268309.23.0.687857784154.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Grr.  s/docstring/docs/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Fri May  7 23:39:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 21:39:31 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1273268371.63.0.590673717509.issue1054967@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We forgot to reopen the bug.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Fri May  7 23:48:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 21:48:12 +0000
Subject: [issue8620] wrong truncation of last line in cmd.Cmd
In-Reply-To: <1273059355.74.0.713627995995.issue8620@psf.upfronthosting.co.za>
Message-ID: <1273268892.09.0.593816051319.issue8620@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Setting version to 3.2, since this change would not be backward compatible and 2.7 is already in beta.

----------
components: +Library (Lib) -None
nosy: +merwok
title: wrong truncation of line in Cmd.cmd -> wrong truncation of last line in cmd.Cmd
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8620>
_______________________________________

From report at bugs.python.org  Fri May  7 23:49:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 May 2010 21:49:07 +0000
Subject: [issue8655] Problem with getpeercert in the ssl module when
	retrieving client side certs
In-Reply-To: <1273267442.54.0.446798585717.issue8655@psf.upfronthosting.co.za>
Message-ID: <1273269093.4188.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When I use the argument to make certs optional, it gave me an error
> saying it need the ca certs, so I downloaded them and specified to use
> them, and now I am getting errors from ssl.c

You have to specify the CA cert corresponding to the Certificate
Authority (CA) who has signed your certificate.
A CA can be a company such as Verisign, etc.

However, in this case, you have self-signed the certificate; so the only
"CA cert" you can specify is the client certificate itself. If you
specify "client.crt" as the ca_certs argument, you'll see that it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8655>
_______________________________________

From report at bugs.python.org  Fri May  7 23:51:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 21:51:21 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1273269081.07.0.0687718904128.issue8604@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri May  7 23:52:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 21:52:26 +0000
Subject: [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1273269146.68.0.683724585122.issue8602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now that #8601 is closed, would you mind providing a doc patch explaining the lack of context manager protocol support and its reason?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8602>
_______________________________________

From report at bugs.python.org  Fri May  7 23:53:40 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 07 May 2010 21:53:40 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1273269220.84.0.552417057863.issue1054967@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Please don't. I've closed this bug because the bdist_deb command is currently managed by the stdeb project and it's fine like htis. Distutils2 will not have specialized linux bdist_* command like this one, because it is best to keep it in a separate project that can evolve as its own pace, in accordance with debian/ubuntu cycles.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Fri May  7 23:54:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 21:54:31 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273269271.17.0.191357629461.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I've been thinking about this a bit more.  There are three types of symbols in unicodeobject.h:

1. Functions that are always safe to use
2. Functions that are only safe if the module is compiled with the same Unicode settings as Python
3. Structures and macros that are only safe if the module is compiled with the same Unicode settings as Python

The functions in #2 will generate a link error if the module actually uses them.  

We can add some symbols next to the structures and macros (#3), such that there will always be a link error if the Unicode settings are mismatched.  However, we can't tell if the module actually uses the structure or not.

The hard question is: what should be declared by default?

Option 1: Make Unicode-agnosticism the default and force anyone who cares about the Unicode setting to include a separate header.  If they don't include that header, they can only call safe functions and can't poke at PyUnicodeObject's internals.  If they include the header, their module will always generate a link failure if the Unicode settings are mismatched.  (Guido proposed this solution in the python-ideas thread)

Option 2: Make Unicode-dependence the default.  If the compilation settings don't match, force a link failure.  Allow extension authors to define a flag (Py_UNICODE_AGNOSTIC) before including Python.h to avoid defining any unsafe functions, structures, or macros.  In practice, this is what Python 3 does today, except there's currently no way to declare Unicode-agnosticism.

Option 3: Go for a middle ground.  Modules are Unicode agnostic by default, unless they call a non-agnostic function (which will cause a link error if there's a mismatch).  If they want to poke directly into PyUnicodeObject, they still need to include a separate header.  I fear that this is the worst of both worlds, though.

The more I think about it, the more I like the first option.

Maybe I should bring this up on capi-sig and try to gather a consensus?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 00:35:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 May 2010 22:35:35 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273271735.96.0.800586648716.issue8638@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Double underscore name mangling is for avoiding name clashes with base classes, not for 'private attributes'. This is such an advanced and rarely used feature that it hardly seems appropriate for the tutorial.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Sat May  8 00:36:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 22:36:03 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1273271763.35.0.889902595535.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Let's try with something: pyunicode_asencodefsdefault.patch adds PyUnicode_EncodeFSDefault() function to uniformize how a unicode is converted to bytes. Fallback to UTF-8 if Py_FileSystemEncoding is not set (I should be ASCII, not UTF-8) and use surrogateescape error handler.

----------
keywords: +patch
Added file: http://bugs.python.org/file17251/pyunicode_encodefsdefault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sat May  8 00:38:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 May 2010 22:38:25 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273271905.6.0.866555469658.issue8654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Adding MvL because he wrote the ABI PEP, and MAL because he cares about the Unicode interface.

----------
nosy: +lemburg, loewis, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 00:39:34 2010
From: report at bugs.python.org (Clovis Fabricio)
Date: Fri, 07 May 2010 22:39:34 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273271974.52.0.0941915171839.issue8638@psf.upfronthosting.co.za>


Clovis Fabricio <nosklo+python at gmail.com> added the comment:

I help in #python and always suggest people to not use double-underscore name mangling when they mean private. 
I agree that name mangling shouldn't be on the tutorial at all. It misleads everybody coming from other languages into thinking that it means "private" like it does in java or C++.

----------
nosy: +nosklo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Sat May  8 00:42:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 22:42:25 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273272145.36.0.528306963802.issue8654@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 01:17:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 May 2010 23:17:25 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1273274245.88.0.763573135916.issue8641@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

u'whatever' is not valid syntax for 3.x.
In any case, with IDLE on my WinXP 3.1.2 system, all string literals are green, with or without a leading b.

If you want this to stay open, cut and paste the opening header like
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32
and some actual code and specify what you see and what you think is wrong.

----------
nosy: +tjreedy
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8641>
_______________________________________

From report at bugs.python.org  Sat May  8 01:17:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 23:17:39 +0000
Subject: [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273274259.29.0.74029545367.issue8642@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is it possible for you to propose a patch, as described in http://www.python.org/dev/patches/ ?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8642>
_______________________________________

From report at bugs.python.org  Sat May  8 01:46:16 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 May 2010 23:46:16 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1273275976.75.0.510435818737.issue8547@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed again revision 80946 after getting the tests to pass on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Sat May  8 01:51:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 May 2010 23:51:08 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273276268.34.0.154592646957.issue8610@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I realized that fallback to ASCII instead of UTF-8 is not possible yet because of #8611: if it fallbacks to ASCII, it's not more possible to run Python in a non-ASCII directory. I have a patch set fixing #8611 but it's huge and complex. I will not be fixed quickly (if it would be possible someday to fix it).

My new patch fallback to utf-8 instead of ascii, even if I agree that it would be better to fallback to ascii. Improve unicode, surrogates & friends is complex, and I prefer to fix bugs step by step. I propose to first ensure that Py_FileSystemEncoding is always set, and later write a new patch to fallback to ASCII instead of UTF-8.

Patch version 5:
 - fallback to utf-8 instead of ascii
 - Set Py_FileSystemDefaultEncoding to NULL to Py_Finalize(): thanks to that, it should be possible to call Py_InitializeEx() (initfsencoding()) twice or more
 - initfsencoding() doesn't call _PyCodec_Lookup() on get_codeset() success because  get_codeset() does already call it
 - explain that the fatal error is very unlikely

----------
Added file: http://bugs.python.org/file17252/initfsencoding-5-utf-8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Sat May  8 02:12:39 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 08 May 2010 00:12:39 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273277559.54.0.320956384582.issue8653@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Sat May  8 03:11:45 2010
From: report at bugs.python.org (Matt Wartell)
Date: Sat, 08 May 2010 01:11:45 +0000
Subject: [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1273281105.43.0.651901907963.issue8602@psf.upfronthosting.co.za>


Matt Wartell <matt.wartell+pt at gmail.com> added the comment:

Per request, I have attached a context diff for both bz2.txt and 3.0.txt suitable for http://docs.python.org/library/bz2.html and http://docs.python.org/release/3.0.1/whatsnew/3.0.html respectively. 

The modification in bz2.txt may border on redundant and overly verbose and should be reviewed for style consistency.

I have sanity-checked the modified files with sphinx-build html which generates clean, consistent markup.

----------
keywords: +patch
status: open -> pending
Added file: http://bugs.python.org/file17253/issue-8602.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8602>
_______________________________________

From report at bugs.python.org  Sat May  8 03:43:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 01:43:13 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273282993.57.0.501837608581.issue8653@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I don't see anything that is missing. Its here in the docs 
http://docs.python.org/library/urlparse.html#urlparse-result-object
And also docstrings has the information too.

Could you explain a bit more as what you were expecting and found missing?

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Sat May  8 03:45:28 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sat, 08 May 2010 01:45:28 +0000
Subject: [issue8656] urllib2 mangles file://-scheme URLs
In-Reply-To: <1273283128.63.0.607654661421.issue8656@psf.upfronthosting.co.za>
Message-ID: <1273283128.63.0.607654661421.issue8656@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

$ touch /tmp/x.html
$ python -c 'import urllib2;resp=urllib2.urlopen("file:///tmp/x.html");print resp.geturl()'
file:/tmp/x.html

note the missing // after the colon

----------
messages: 105250
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urllib2 mangles file://-scheme URLs
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8656>
_______________________________________

From report at bugs.python.org  Sat May  8 03:45:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 01:45:31 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273283131.82.0.41682553339.issue8644@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> (1) there should be a Py_DECREF(total_microseconds) ...

Yes, regrtest -R is not a substitute for thinking.

> (2) in the docstring, replace 'loose' by 'lose'
>

Neither is spellcheck. :-)

> (3) also in the docstring, I suggest replacing "280 years" by "270 years" ...

Yes, and precision is not accuracy.

----------
Added file: http://bugs.python.org/file17254/issue8644-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 03:45:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 01:45:44 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273283144.76.0.178598438399.issue8644@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17246/issue8644-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 03:47:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 01:47:47 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273283267.87.0.136600408491.issue8644@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17255/issue8644-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 03:47:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 01:47:56 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273283276.38.0.837032331902.issue8644@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17254/issue8644-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 04:17:09 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Sat, 08 May 2010 02:17:09 +0000
Subject: [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273285029.17.0.980027181507.issue8642@psf.upfronthosting.co.za>


MATSUI Tetsushi <mft at users.sourceforge.net> added the comment:

OK, here you are.

----------
keywords: +patch
Added file: http://bugs.python.org/file17256/json.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8642>
_______________________________________

From report at bugs.python.org  Sat May  8 04:49:08 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sat, 08 May 2010 02:49:08 +0000
Subject: [issue8657] urlparse.urlunsplit should be smarter about +
In-Reply-To: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>
Message-ID: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

from urlparse import *
urlunsplit(urlsplit('git+file:///foo/bar/baz'))
=> git+file:/foo/bar/baz

----------
messages: 105253
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about +
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8657>
_______________________________________

From report at bugs.python.org  Sat May  8 05:06:51 2010
From: report at bugs.python.org (Puzzlet Chung)
Date: Sat, 08 May 2010 03:06:51 +0000
Subject: [issue8641] IDLE 3 doesn't highlights b"", but u""
In-Reply-To: <1273212994.94.0.428777321336.issue8641@psf.upfronthosting.co.za>
Message-ID: <1273288011.68.0.67367436588.issue8641@psf.upfronthosting.co.za>


Puzzlet Chung <puzzlet at gmail.com> added the comment:

> In any case, with IDLE on my WinXP 3.1.2 system, all string literals are green, with or without a leading b.

The letter b should also be green, while it shows the letter u from u'string' in green, which it shouldn't as it's not valid anymore.

Tested in IDLE with following version of Python:

Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] on win32

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8641>
_______________________________________

From report at bugs.python.org  Sat May  8 05:32:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 03:32:28 +0000
Subject: [issue8656] urllib2 mangles file://-scheme URLs
In-Reply-To: <1273283128.63.0.607654661421.issue8656@psf.upfronthosting.co.za>
Message-ID: <1273289548.31.0.41539296338.issue8656@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r80953, r80954 , r80955 and r80956.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8656>
_______________________________________

From report at bugs.python.org  Sat May  8 06:00:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 04:00:34 +0000
Subject: [issue8658] urlparse.urlunsplit should be smarter about + and file
	urls
In-Reply-To: <1273291234.63.0.786087724907.issue8658@psf.upfronthosting.co.za>
Message-ID: <1273291234.63.0.786087724907.issue8658@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

>>> from urlparse import *
>>> urlsplit('git+file:///foo/bar/baz')
SplitResult(scheme='git+file', netloc='', path='/foo/bar/baz', query='', fragment='')
>>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
'git+file:/foo/bar/baz'
>>>

----------
assignee: orsenthil
files: urlparse_giturl.patch
keywords: patch
messages: 105256
nosy: orsenthil
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about + and file urls
type: behavior
Added file: http://bugs.python.org/file17257/urlparse_giturl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8658>
_______________________________________

From report at bugs.python.org  Sat May  8 06:01:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 04:01:01 +0000
Subject: [issue8658] urlparse.urlunsplit should be smarter about + and file
	urls
In-Reply-To: <1273291234.63.0.786087724907.issue8658@psf.upfronthosting.co.za>
Message-ID: <1273291261.61.0.661682211241.issue8658@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +dabrahams

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8658>
_______________________________________

From report at bugs.python.org  Sat May  8 06:07:53 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 04:07:53 +0000
Subject: [issue8657] urlparse.urlunsplit should be smarter about +
In-Reply-To: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>
Message-ID: <1273291673.54.0.244465739791.issue8657@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
keywords: +patch
nosy: +orsenthil
resolution:  -> accepted
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file17258/urlparse_giturl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8657>
_______________________________________

From report at bugs.python.org  Sat May  8 06:08:07 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 04:08:07 +0000
Subject: [issue8658] urlparse.urlunsplit should be smarter about + and file
	urls
In-Reply-To: <1273291234.63.0.786087724907.issue8658@psf.upfronthosting.co.za>
Message-ID: <1273291687.61.0.20906869022.issue8658@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Duplicate of Issue8657

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8658>
_______________________________________

From report at bugs.python.org  Sat May  8 06:34:50 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 08 May 2010 04:34:50 +0000
Subject: [issue8656] urllib2 mangles file://-scheme URLs
In-Reply-To: <1273283128.63.0.607654661421.issue8656@psf.upfronthosting.co.za>
Message-ID: <1273293290.64.0.655404925693.issue8656@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Major buildbot failures caused by this change, eg:

ERROR: test_file (test.test_urllib2net.OtherNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py", line 126, in test_file
    self._test_urls(urls, self._extra_handlers(), retry=True)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py", line 175, in _test_urls
    f = urlopen(url, req, TIMEOUT)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py", line 28, in wrapped
    return _retry_thrice(func, exc, *args, **kwargs)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/test/test_urllib2net.py", line 19, in _retry_thrice
    return func(*args, **kwargs)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", line 391, in open
    response = self._open(req, data)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", line 409, in _open
    '_open', req)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", line 1257, in file_open
    return self.open_local_file(req)
  File "/home/buildbot/slave/py-build/2.6.norwitz-amd64/build/Lib/urllib2.py", line 1291, in open_local_file
    headers, 'file://'+ host + file)
TypeError: cannot concatenate 'str' and 'NoneType' objects

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8656>
_______________________________________

From report at bugs.python.org  Sat May  8 06:37:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 04:37:56 +0000
Subject: [issue8656] urllib2 mangles file://-scheme URLs
In-Reply-To: <1273293290.64.0.655404925693.issue8656@psf.upfronthosting.co.za>
Message-ID: <j2m7c42eba11005072137gc8c97952r9f82ad6f74fb1d72@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, May 8, 2010 at 10:04 AM, Jean-Paul Calderone
<report at bugs.python.org> wrote:
> TypeError: cannot concatenate 'str' and 'NoneType' objects

Okay, I see where the problem is. I shall quickly fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8656>
_______________________________________

From report at bugs.python.org  Sat May  8 06:46:28 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Sat, 08 May 2010 04:46:28 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273293988.56.0.556465750639.issue8654@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

> Option 1: Make Unicode-agnosticism the default and force anyone who cares about the Unicode setting to include a separate header.  If they don't include that header, they can only call safe functions and can't poke at PyUnicodeObject's internals.  If they include the header, their module will always generate a link failure if the Unicode settings are mismatched.  (Guido proposed this solution in the python-ideas thread)

+1

The packaging and compatibility problems are pressing concerns for many people. Poking at PyUnicodeObject's internals seems like a rare pretty rare need for an extension module to do. If I understand correctly, this option provides the best solution to the packaging and compatibility issues (over the long term, as Python and the authors of extension modules upgrade).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 06:52:07 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 08 May 2010 04:52:07 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273271735.96.0.800586648716.issue8638@psf.upfronthosting.co.za>
Message-ID: <z2h9cee7ab81005072151g6d7f54d2w6e4a4022d1e3834d@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Fri, May 7, 2010 at 6:35 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> This is such an advanced and rarely used feature that it hardly seems appropriate for the tutorial.

The problem with just leaving it out is that learners stumbling over
them in existing code (likely by trying to use something that looks
like it should be there and getting an AttributeError) won't have a
chance of knowing what the problem might be.

I'd be fine seeing new uses discouraged, especially for new learners,
but I think it's important that they be given a heads-up as well.

  -Fred

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Sat May  8 06:53:17 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 08 May 2010 04:53:17 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273294397.26.0.355991700742.issue8513@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I think your partA patch makes sense.

It would benefit from fsencode/fsdecode functions rather than manually doing the 'surrogateescape' thing everywhere.

Also, could you add a unittest for os._execvpe to test its behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat May  8 07:15:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 05:15:54 +0000
Subject: [issue8656] urllib2 mangles file://-scheme URLs
In-Reply-To: <1273293290.64.0.655404925693.issue8656@psf.upfronthosting.co.za>
Message-ID: <20100508051543.GA2230@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed the change which resulted in Buildbots failure. Those should
turn green now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8656>
_______________________________________

From report at bugs.python.org  Sat May  8 07:25:30 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 08 May 2010 05:25:30 +0000
Subject: [issue8514] Create fsencode() and fsdecode() functions in os.path
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273296329.97.0.527975218172.issue8514@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

+.. function:: fsencode(value)
+
+   Encode *value* to bytes for use in the file system, environment variables or
+   the command line.  Use :func:`sys.getfilesystemencoding` and
+   ``'surrogateescape'`` error handler for str, and keep bytes unchanged.

I'd word the latter sentence as:

Uses :func:`sys.getfilesystemencoding` and ``'surrogateescape'`` error handler for strings and returns bytes unchanged.


Otherwise I think this patch looks good.  +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat May  8 08:15:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 06:15:22 +0000
Subject: [issue8659] ABS(x) == 0 can be simplified to x == 0
In-Reply-To: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>
Message-ID: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

I noticed that in longobject.c, there are a few spots that take the absolute value of an int before comparing the int to 0.  There's no -0 for C integers, so the absolute value isn't necessary.

I traced back through the commit history, and it looks like they're an artifact of the original one's-complement longobject.c (which COULD have -0).  longobject was switched to two's-complement in 1992. ;-)

----------
assignee: stutzbach
components: Interpreter Core
files: abs-zero.patch
keywords: patch
messages: 105265
nosy: stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: ABS(x) == 0 can be simplified to x == 0
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17259/abs-zero.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8659>
_______________________________________

From report at bugs.python.org  Sat May  8 08:15:57 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 06:15:57 +0000
Subject: [issue8659] ABS(x) == 0 can be simplified to x == 0
In-Reply-To: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>
Message-ID: <1273299357.01.0.433060892053.issue8659@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8659>
_______________________________________

From report at bugs.python.org  Sat May  8 08:21:19 2010
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Sat, 08 May 2010 06:21:19 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1273299679.17.0.10240001188.issue4171@psf.upfronthosting.co.za>


Dmitry Dvoinikov <dmitry at targeted.org> added the comment:

Checked out and built revision 80956 of py3k against OpenSSL 0.9.8n. Here is the banner:

Python 3.2a0 (py3k:80956, May  8 2010, 11:31:45) [MSC v.1500 32 bit (Intel)] on win32

Now, the breaking script appears not to be breaking any more, even though I tried it in a loop, a 1000 attempts to execute were all successful. 

It seems to be fine now, thank you for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Sat May  8 10:05:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 08:05:07 +0000
Subject: [issue8659] ABS(x) == 0 can be simplified to x == 0
In-Reply-To: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>
Message-ID: <1273305907.19.0.953281822178.issue8659@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks!  Fixed in r80961 (trunk) and r80962 (py3k).

BTW, are there any particular commit messages or news entries that indicate a switch to two's complement?  I've looked for these in the past, but not found them.

----------
nosy: +mark.dickinson
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8659>
_______________________________________

From report at bugs.python.org  Sat May  8 10:41:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 08:41:55 +0000
Subject: [issue8659] ABS(x) == 0 can be simplified to x == 0
In-Reply-To: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>
Message-ID: <1273308115.69.0.643080267318.issue8659@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I found:

- Long integer shift/mask operations now simulate 2's complement
  to give more useful results for negative operands

in Misc/HISTORY, for the Python 0.9.6 release.  That's different, though:  it's about Python's semantics, not C's.  It's orthogonal to the question of whether the underlying C implementation uses two's complement, ones' complement or sign-magnitude.

I can't find any explicit indication of a decision to assume that the hardware integers are two's complement anywhere;  as far as I know, no such decision was ever taken.

But of course your simplifications are valid regardless of the integer representation of the machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8659>
_______________________________________

From report at bugs.python.org  Sat May  8 10:45:24 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 08 May 2010 08:45:24 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1273308324.76.0.661143258014.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed to the trunk in r80963.

I'm not closing this yet because the patch needs to be ported to 3.2 at least, and preferably 2.6 and 3.1 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sat May  8 10:45:39 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 08 May 2010 08:45:39 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1273308339.23.0.895883592096.issue7724@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sat May  8 10:46:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 08 May 2010 08:46:48 +0000
Subject: [issue8444] openssl version detection doesn't work properly when
	using OSX SDK
In-Reply-To: <1271623450.52.0.5635482395.issue8444@psf.upfronthosting.co.za>
Message-ID: <1273308408.86.0.484250937678.issue8444@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing because the patch in issue 7724 fixes this problem.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8444>
_______________________________________

From report at bugs.python.org  Sat May  8 12:03:24 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 08 May 2010 10:03:24 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273313004.86.0.0559347235111.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the update to 2.65 on the py3k branch only did show whitespace changes, applying these changes to the trunk.

r80964: require autoconf-2.65

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sat May  8 12:03:51 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 May 2010 10:03:51 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <4BE53701.7030207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Daniel Stutzbach wrote:
> 
> New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:
> 
> Currently, Python can be built with an internal Unicode representation of UCS2 or UCS4.  To prevent extension modules compiled with the wrong Unicode representation from linking, unicodeobject.h #defines many of the Unicode functions.  For example, PyUnicode_FromString becomes either PyUnicodeUCS2_FromString or PyUnicodeUCS4_FromString.
> 
> Consequently, if one installs a binary egg (e.g., with easy_install), there's a good chance one will get an error such as the following when trying to use it:
> 
>         undefined symbol: PyUnicodeUCS2_FromString
> 
> In Python 2, only some extension modules were stung by this problem.  For Python 3, virtually every extension type will need to call a PyUnicode_* function, since __repr__ must return a Unicode object.  It's basically fruitless to upload a binary egg for Python 3 to PyPi, since it will generate link errors for a large fraction of downloaders (I discovered this the hard way).
> 
> Right now, nearly all the functions in unicodeobject.h are wrapped.  Several functions are not.  Many of the unwrapped functions also have no documentation, so I'm guessing they are newer functions that were not wrapped when they were added.

That's true. The main point in wrapping the APIs was to make sure that
if an extension module uses Unicode, it will likely use one of the
wrapped APIs and then be protected by the name mangling to prevent
extensions compiled as UCS2 to be loaded into a UCS4 interpreter
and vice-versa.

The main difference between those two build variants is the definition
of Py_UNICODE. Unfortunately, there's no way to have the linker check
that type definition. The wrapping was chosen as alternative protection.

> Most extensions treat PyUnicodeObjects as opaque and do not care if the internal representation is UCS2 or UCS4.  We can improve ABI compatibility by only wrapping functions where the representation matters from the caller's point of view.
> 
> For example, PyUnicode_FromUnicode creates a Unicode object from an array of Py_UNICODE objects.  It will interpret the data differently on UCS2 vs UCS4, so the function should be wrapped.
>
> On the other hand, PyUnicode_FromString creates a Unicode object from a char *.  The caller can treat the returned object as opaque, so the function should not be wrapped.

The point of the wrapping was not to protect the APIs themselves.
It is just meant to be able to use the linker as protection device
when loading a module.

If you can propose a different method of reliably protecting against
mixed Unicode build module loads, that would be great. We could then
get rid off the wrapping altogether.

> The attached patch implements that rule.  It unwraps 64 opaque functions that were previously wrapped, and wraps 11 non-opaque functions that were previously unwrapped.  "make test" works with both UCS2 and UCS4 builds.

I don't think that removing a few wrapped function is going to help
with the problem.

Extension modules can still use Py_UNICODE internally and make
use of the macros we have for accessing the PyUnicodeObject
internals. You simply don't catch such usage with wrapping
the APIs - as I said above: it's not a perfect solution, but
only a method that works most of the time.

I'd much rather like to see a solution that always works rather
than making mixed Unicode build extension loading easier.

Perhaps we could do something in the module import mechanism
to check for Unicode build compatibility (much like the Python API
version check, but with raising an error instead of just issuing
a warning).

> I previously brought this issue up on python-ideas, see:
> http://mail.python.org/pipermail/python-ideas/2009-November/006543.html
> 
> Here's a summary of that discussion:
> 
> Zooko Wilcox-O'Hearn pointed out that my proposal is complimentary to his proposal to standardize on UCS4, to reduce the risk of extension modules built with a mismatched encoding.
> 
> Stefan Behnel pointed out that easy_install should allow eggs to specify the encoding they require.  PJE's proposed implementation of that feature (http://bit.ly/1bO62) would allow eggs to specify UCS2, UCS4, or "Don't Care".  My proposal greatly increases the number of eggs that could label themselves "Don't Care", reducing maintenance work for package maintainers.  In other words, they are complimentary fixes.
> 
> Guido liked the idea but expressed concern about the possibility of extension modules that link successfully, but later crash because they actually do depend on the UCS2/UCS4 distinction.
> 
> With my current patch, there are still two ways for that to happen:
> 
> 1) The extension uses only opaque functions, but casts the returned PyObject * to PyUnicodeObject * and accesses the str member, or
> 
> 2) The extension uses only opaque functions, but uses the PyUnicode_AS_UNICODE or PyUnicode_AS_DATA macros.
> 
> Most packages that poke into the internals of PyUnicodeObject also call non-opaque functions.  Consequently, they will still generate a linker error if the encoding is mismatched, as desired.
> 
> I'm trying to come up with a way to 100% guarantee that any extension poking into the internals will generate a linker error if the encoding is mismatched, even if they don't call any non-opaque functions.  I'll post about that in a separate comment to this bug.

Please note that UCS2 and UCS4 builds of Python are different in
more ways than just the underlying Py_UNICODE type. E.g. UCS2 builds
use surrogates when converting between Unicode and bytes which
UCS4 don't, sys.maxunicode is different, range checks use different
bounds, unichr() behaves differently, etc. etc.

It is simply not a good idea to have modules build for a UCS2
interpreter work in a UCS4 interpreter and vice-versa.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 12:07:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 10:07:44 +0000
Subject: [issue8659] ABS(x) == 0 can be simplified to x == 0
In-Reply-To: <1273299322.78.0.204722147586.issue8659@psf.upfronthosting.co.za>
Message-ID: <1273313264.4.0.5447223523.issue8659@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, now I understand :)

r2604 introduced a scheme where for a negative PyLongObject x with n digits, the value stored in x->ob_size was -1-n.  A little like ones' complement, but unrelated to anything to do with the platform integer representation.  So at that stage there were two possible internal representations of 0L, which is why all the ZABS() stuff was necessary to make sure that those two representations of 0L compared equal.

r2751 (in 1992, indeed!) reversed this, using -n instead of -1-n for this case, but didn't remove the extra tests for the two different representations of 0L.  r2751 also changed the semantics of long bitwise operations for negative numbers, but that's not relevant to this issue.

Sorry for being slow.

It's impressive that this piece of redundant code has survived this long.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8659>
_______________________________________

From report at bugs.python.org  Sat May  8 12:30:03 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 08 May 2010 10:30:03 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273314603.3.0.629326082496.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed to the trunk in r80967.

Reducing the priority because this is no longer a release-blocker for the next 2.7 release.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat May  8 12:50:17 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 08 May 2010 10:50:17 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273315817.47.0.614141991587.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

And committed to 3.2 in r80968

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat May  8 12:58:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 10:58:34 +0000
Subject: [issue8514] Add fsencode() functions to os module
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273316314.87.0.0761745081635.issue8514@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Create fsencode() and fsdecode() functions in os.path -> Add fsencode() functions to os module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat May  8 13:01:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 11:01:38 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273316498.2.0.317066353337.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think your partA patch makes sense.

I can fix part A and B in two commits.

> It would benefit from fsencode/fsdecode functions rather 
> than manually doing the 'surrogateescape' thing everywhere.

I choosed to drop the idea of fsdecode() (patch for part A doesn't decode bytes anymore, it only encodes str). #8514 has now a short and simple patch. I'm waiting for the final decision on #8514 to commit the part A.

> Also, could you add a unittest for os._execvpe to test its behavior?

os._execvpe() is a protected function. issue8513_partA.patch includes a test for subprocess. test_subprocess in two twices: with _posixsubprocess (C module) and with the pure Python implementation. The pure Python implementation calls os._execvpe(), that's why I patched also this function in my patch ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat May  8 13:09:07 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 08 May 2010 11:09:07 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273316947.9.0.355368422918.issue8510@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

r80965: Replace AC_HELP_STRING with AS_HELP_STRING
r80966: s/AC_AIX/AC_USE_SYSTEM_EXTENSIONS/
r80969: convert all obsolete AC_TRY_* macros to AC_*_IFELSE
r80970: Avoid autoconf warning: Assume C89 semantics that RETSIGTYPE is always void

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sat May  8 13:12:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 11:12:39 +0000
Subject: [issue8514] Add fsencode() functions to os module
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273317159.58.0.366337686801.issue8514@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r80971 (py3k), blocked by r80972 (3.1).

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat May  8 13:15:26 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 08 May 2010 11:15:26 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1273317326.07.0.710924994582.issue8490@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I have adjusted the failing tests in r80895 and r80930 which now pass on Solaris. 
It seems Solaris has two problems:

 - OOB data (aka handle_expt) doesn't work, but I'm not too worried about this as it's very rarely used. In past there have been proposals to remove its support, so I'd be for leaving it as it is.

- connect() connects immediately, even before starting the poller.
Now, this may be a problem when writing clients which implement some logic in their handle_connect() method.
Since handle_connect() gets called immediately if the user tries to, say, send some data over the socket, the dispatcher will immediately be closed as the socket is actually still disconnected.

I'd be for starting to commit the patch in attachment which skips such tests on SunOS, then if someone could give me SSH access over the Solaris box used for buildbots I could try to debug the connect() problem and see if I can fix it.

----------
Added file: http://bugs.python.org/file17260/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Sat May  8 13:16:53 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 08 May 2010 11:16:53 +0000
Subject: [issue8657] urlparse.urlunsplit should be smarter about +
In-Reply-To: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>
Message-ID: <1273317413.34.0.0258438653981.issue8657@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

Is simply adding 'git+' entries comprehensive enough?  I'd have said the same thing about the addition of the 'svn+' entries, fwiw :)  Is adding hardcoded entries like this the preferred way to extend urlparse?

----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8657>
_______________________________________

From report at bugs.python.org  Sat May  8 13:20:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 11:20:05 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273317605.87.0.37615237516.issue8084@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> And committed to 3.2 in r80968

This commit introduced a regression:

http://www.python.org/dev/buildbot/all/builders/AMD64 Ubuntu wide 3.x/builds/1055

======================================================================
FAIL: test_get_scheme_names (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/test/test_sysconfig.py", line 239, in test_get_scheme_names
    self.assertEquals(get_scheme_names(), wanted)
AssertionError: Tuples differ: ('nt', 'nt_user', 'os2', 'os2_... != ('nt', 'nt_user', 'os2', 'os2_...

First differing element 4:
osx_framework_user
posix_home

First tuple contains 1 additional elements.
First extra element 7:
posix_user

  ('nt',
   'nt_user',
   'os2',
   'os2_home',
-  'osx_framework_user',
   'posix_home',
   'posix_prefix',
   'posix_user')

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat May  8 13:21:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 11:21:58 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273317718.73.0.691896321286.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update the patch to use os.fsencode().

----------
Added file: http://bugs.python.org/file17261/issue8513_partA-fsencode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat May  8 14:54:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 May 2010 12:54:58 +0000
Subject: [issue8638] Remove suggestion for name mangling from the tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1273323298.39.0.0265159478404.issue8638@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The section titled "Private Variables" was updated fairly recently to be more in line with the Python philosophy.  In its current form (which I verified to be present at e.g. http://docs.python.org/tutorial/classes#private-variables) I don't think it needs to be removed or revised (except for further clarification, of course.)

If someone disagrees, I would like to see a patch (or a suggestion for new wording).

----------
nosy: +georg.brandl
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8638>
_______________________________________

From report at bugs.python.org  Sat May  8 15:07:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 08 May 2010 13:07:48 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I propose a different approach:

1. add a flag to PyModuleDef, indicating whether the module was built in UCS-2 or UCS-4 mode. Then let the interpreter refuse the load the module, instead of having the dynamic linker do so.
2. provide a mode for the header files where Py_UNICODE is not defined. add another flag to PyModuleDef indicating whether that mode was used when compiling the extension.

Module authors then can make a choice whether or not to refer to the Unicode internal representation in their module. If they do, a UCS-2 version won't load into a UCS-4 interpreter. If they don't refer to Py_UNICODE at all, the module can be used across the two modes.

There is a slight risk that a module may already crash before calling PyModule_Create. To prevent that, we need to specify that no Unicode API must be used before calling PyModule_Create.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 15:10:10 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 08 May 2010 13:10:10 +0000
Subject: [issue8660] py3k weakref documentation mentions the long built-in type
In-Reply-To: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>
Message-ID: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

There is a sentence in the weakref module's documentation:
"Other built-in types such as tuple and long do not support weak references even when subclassed"
But there is no "long" type in py3k.

----------
assignee: docs at python
components: Documentation
messages: 105285
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: py3k weakref documentation mentions the long built-in type
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8660>
_______________________________________

From report at bugs.python.org  Sat May  8 15:15:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 May 2010 13:15:30 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za>
Message-ID: <4BE563ED.1040809@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> I propose a different approach:
> 
> 1. add a flag to PyModuleDef, indicating whether the module was built in UCS-2 or UCS-4 mode. Then let the interpreter refuse the load the module, instead of having the dynamic linker do so.
> 2. provide a mode for the header files where Py_UNICODE is not defined. add another flag to PyModuleDef indicating whether that mode was used when compiling the extension.
> 
> Module authors then can make a choice whether or not to refer to the Unicode internal representation in their module. If they do, a UCS-2 version won't load into a UCS-4 interpreter. If they don't refer to Py_UNICODE at all, the module can be used across the two modes.
> 
> There is a slight risk that a module may already crash before calling PyModule_Create. To prevent that, we need to specify that no Unicode API must be used before calling PyModule_Create.

+1

We could then get rid off the API renaming altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 15:15:37 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 13:15:37 +0000
Subject: [issue7780] unittest: allow an 'import_path' as an alternative to
	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1273324537.2.0.752507142925.issue7780@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Tested in revision 79643. Still needs docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7780>
_______________________________________

From report at bugs.python.org  Sat May  8 15:16:28 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 13:16:28 +0000
Subject: [issue7780] unittest: allow an 'import_path' as an alternative to
	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1273324588.85.0.970435894172.issue7780@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7780>
_______________________________________

From report at bugs.python.org  Sat May  8 15:20:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 13:20:46 +0000
Subject: [issue7780] unittest: allow an 'import_path' as an alternative to
	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1273324846.88.0.890488476161.issue7780@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Test committed revision 80974.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7780>
_______________________________________

From report at bugs.python.org  Sat May  8 16:05:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 14:05:09 +0000
Subject: [issue4171] SSL handshake fails after TCP connection in getpeername()
In-Reply-To: <1224675444.68.0.815389836032.issue4171@psf.upfronthosting.co.za>
Message-ID: <1273327509.88.0.922963570148.issue4171@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4171>
_______________________________________

From report at bugs.python.org  Sat May  8 16:07:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 14:07:35 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273327655.42.0.982773544455.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks good to me.

I definitely think this should go into 2.7 as well;  total_seconds has only seen the light of day in the beta releases so far, so it's unlikely we'd break anyone's code with this change.  (And IMO this is a bugfix, not a feature.)

It might be polite to wait a day or two for the 2.7 backport, though:  2.7 beta 2 is supposed to be being released today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 16:08:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 14:08:13 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273327693.59.0.779270906707.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If you want a second (third?) opinion, we could ask Antoine.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 16:18:54 2010
From: report at bugs.python.org (Bernhard Reiter)
Date: Sat, 08 May 2010 14:18:54 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1273328334.49.0.541268041585.issue6715@psf.upfronthosting.co.za>


Changes by Bernhard Reiter <ockham at raz.or.at>:


----------
nosy: +ockham-razor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sat May  8 16:30:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 08 May 2010 14:30:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1273329020.49.0.448557326658.issue6715@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sat May  8 16:30:46 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 08 May 2010 14:30:46 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273329046.93.0.549162067764.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Is this is still desirable?
If so I can work on a patch for ftplib which provides a finer error handling in case of disconnection while sending QUIT and updates tests which should be modified to fit in the newer test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sat May  8 16:30:58 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 08 May 2010 14:30:58 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273329058.59.0.697177351277.issue4972@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sat May  8 16:31:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 08 May 2010 14:31:20 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273329080.89.0.381449970898.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Is this still desirable?
If so I can work on a patch for ftplib which provides a finer error handling in case of disconnection while sending QUIT and updates tests which should be modified to fit in the newer test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sat May  8 16:36:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 14:36:41 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273329401.53.0.285796117502.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Antoine declines to offer an opinion.]

Committed to py3k in r80979.  I moved the Misc/NEWS entry from the 'Library' section to the 'Extension Modules' section.

Leaving open for the 2.7 backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 16:36:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 14:36:57 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273329417.66.0.744736585587.issue8644@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> accepted
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sat May  8 17:01:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 15:01:08 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <4BE53701.7030207@egenix.com>
Message-ID: <r2zeae285401005080801kfb7fe0d4t2dc7e71660cc8fb3@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 5:03 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> If you can propose a different method of reliably protecting against
> mixed Unicode build module loads, that would be great. We could then
> get rid off the wrapping altogether.

The following code will cause a link error 100% of the time iff
there's a mismatch:

#ifndef Py_UNICODE_WIDE
#define _Py_Unicode_Build_Symbol _Py_UCS2_Build_Symbol
#else
#define _Py_Unicode_Build_Symbol _Py_UCS4_Build_Symbol
#endif
extern int _Py_Unicode_Build_Symbol; /* Defined in unicodeobject.c */
static int *_Py_Unicode_Build_Symbol_Check = &_Py_Unicode_Build_Symbol;

In practice, I'd surrounded it with a bunch #ifdefs to disable the
"defined but not used" warning in gcc and MSVC.

> Please note that UCS2 and UCS4 builds of Python are different in
> more ways than just the underlying Py_UNICODE type. E.g. UCS2 builds
> use surrogates when converting between Unicode and bytes which
> UCS4 don't, sys.maxunicode is different, range checks use different
> bounds, unichr() behaves differently, etc. etc.

That's true, but those differences are visible from pure-Python code
as well aren't they?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 17:12:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 15:12:12 +0000
Subject: [issue7780] unittest: allow an 'import_path' as an alternative to
	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1273331532.15.0.185983955974.issue7780@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Documented revision 80980.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7780>
_______________________________________

From report at bugs.python.org  Sat May  8 17:16:09 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 May 2010 15:16:09 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <r2zeae285401005080801kfb7fe0d4t2dc7e71660cc8fb3@mail.gmail.com>
Message-ID: <4BE58035.9040604@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Daniel Stutzbach wrote:
> 
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
> 
> On Sat, May 8, 2010 at 5:03 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>> If you can propose a different method of reliably protecting against
>> mixed Unicode build module loads, that would be great. We could then
>> get rid off the wrapping altogether.
> 
> The following code will cause a link error 100% of the time iff
> there's a mismatch:
> 
> #ifndef Py_UNICODE_WIDE
> #define _Py_Unicode_Build_Symbol _Py_UCS2_Build_Symbol
> #else
> #define _Py_Unicode_Build_Symbol _Py_UCS4_Build_Symbol
> #endif
> extern int _Py_Unicode_Build_Symbol; /* Defined in unicodeobject.c */
> static int *_Py_Unicode_Build_Symbol_Check = &_Py_Unicode_Build_Symbol;
> 
> In practice, I'd surrounded it with a bunch #ifdefs to disable the
> "defined but not used" warning in gcc and MSVC.

Are you sure this doesn't get optimized away in practice ?

FWIW: I still like the import logic solution better, since that
will make it possible for the user to see a truly useful
error message rather than just some missing symbol linker
error.

>> Please note that UCS2 and UCS4 builds of Python are different in
>> more ways than just the underlying Py_UNICODE type. E.g. UCS2 builds
>> use surrogates when converting between Unicode and bytes which
>> UCS4 don't, sys.maxunicode is different, range checks use different
>> bounds, unichr() behaves differently, etc. etc.
> 
> That's true, but those differences are visible from pure-Python code
> as well aren't they?

Sure, though, I don't see how this relates to C code relying
on these details, e.g. a C extension will probably use different
conversion code depending on whether UCS2 or UCS4 is compatible
with some external library, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 17:25:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 15:25:12 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1273332312.46.0.343128512437.issue7724@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ronald, I've reverted the patch since it broke compilation on almost every buildbot, and we're close to beta2 release.

----------
nosy: +benjamin.peterson
stage: committed/rejected -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sat May  8 17:31:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 15:31:41 +0000
Subject: [issue8660] py3k weakref documentation mentions the long built-in type
In-Reply-To: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>
Message-ID: <1273332701.92.0.364728136484.issue8660@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80983.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8660>
_______________________________________

From report at bugs.python.org  Sat May  8 17:33:42 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 08 May 2010 15:33:42 +0000
Subject: [issue8661] FAQ item 2.25 is unclear
In-Reply-To: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>
Message-ID: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at twistedmatrix.com>:

The item "How do I prepare a new branch for merging?" is unclear about which branch needs to be prepared.  It could be the source branch or the destination branch.  In #python-dev, I learned that it's probably the destination branch being discussed here.  This should be clarified (and it could also be pointed out that it is almost always the case that this step has been done by someone else already).

----------
messages: 105300
nosy: exarkun
priority: normal
severity: normal
status: open
title: FAQ item 2.25 is unclear

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8661>
_______________________________________

From report at bugs.python.org  Sat May  8 17:35:17 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 15:35:17 +0000
Subject: [issue8514] Add fsencode() functions to os module
In-Reply-To: <1272065952.1.0.987702075651.issue8514@psf.upfronthosting.co.za>
Message-ID: <1273332917.26.0.22174788064.issue8514@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Why does this have no tests?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sat May  8 17:48:40 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 15:48:40 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <4BE58035.9040604@egenix.com>
Message-ID: <m2reae285401005080848r8c64cb57m2b74b3001cbf1f06@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 10:16 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> Are you sure this doesn't get optimized away in practice ?

I'm sure it doesn't get optimized away by gcc 4.3, where I tested it. :)

> Sure, though, I don't see how this relates to C code relying
> on these details, e.g. a C extension will probably use different
> conversion code depending on whether UCS2 or UCS4 is compatible
> with some external library, etc.

Can you give an example?

All of the examples I can think of either:
- poke into PyUnicodeObject's internals,
- call a Python function that exposes Py_UNICODE or PyUnicodeObject

I'm explicitly trying to protect those two cases.  It's quite possible
that I'm missing something, but I can't think of any other unsafe way
for a C extension to convert a Python Unicode object to a byte string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 17:59:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 15:59:50 +0000
Subject: [issue8661] FAQ item 2.25 is unclear
In-Reply-To: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>
Message-ID: <1273334390.72.0.428726824281.issue8661@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8661>
_______________________________________

From report at bugs.python.org  Sat May  8 18:02:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 08 May 2010 16:02:29 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1273334549.23.0.707861679428.issue7724@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just to save you some time investigating, it broke the build because
of missing parentheses in setup.py:

if sys.platform == 'darwin' and dir.startswith('/System') or dir.startswith('/usr')

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sat May  8 18:02:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 08 May 2010 16:02:50 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <m2reae285401005080848r8c64cb57m2b74b3001cbf1f06@mail.gmail.com>
Message-ID: <4BE58B27.9000808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Are you sure this doesn't get optimized away in practice ?
> 
> I'm sure it doesn't get optimized away by gcc 4.3, where I tested it. :)

Did you mean to include the hunk from msg105295 as part of the patch?
If so, wouldn't that defeat the whole point of the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:07:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 16:07:53 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1273334873.44.0.236394326667.issue7723@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Documentation can always be updated later.

----------
nosy: +benjamin.peterson
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sat May  8 18:11:00 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 16:11:00 +0000
Subject: [issue8661] FAQ item 2.25 is unclear
In-Reply-To: <1273332822.19.0.471138698588.issue8661@psf.upfronthosting.co.za>
Message-ID: <1273335060.62.0.929927635708.issue8661@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I would also suggest a re-ordering of FAQ entries in this manner:

1st  What tools do I need to merge between branches?
2nd  How do I merge between branches?

And then,
 
How do I prepare a new branch for merging?

With the explanation/clarification.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8661>
_______________________________________

From report at bugs.python.org  Sat May  8 18:11:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 16:11:06 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za>
Message-ID: <x2leae285401005080911uddf5bed2nc4e9b3550e453d33@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 8:07 AM, Martin v. L?wis <report at bugs.python.org> wrote:
> 1. add a flag to PyModuleDef, indicating whether the module was built in UCS-2 or UCS-4 mode. Then let the interpreter refuse the load the module, instead of having the dynamic linker do so.
> 2. provide a mode for the header files where Py_UNICODE is not defined. add another flag to PyModuleDef indicating whether that mode was used when compiling the extension.

I notice that PyModule_Create currently works like this:

PyAPI_FUNC(PyObject *) PyModule_Create2(struct PyModuleDef*, int apiver);
#define PyModule_Create(module) \
        PyModule_Create2(module, PYTHON_API_VERSION)

Instead of modifying PyModuleDef, what if we changed PyModule_Create
to something like the following?

PyAPI_FUNC(PyObject *) PyModule_Create3(struct PyModuleDef*, int apiver);
#define PyModule_Create(module) \
        PyModule_Create3(module, PYTHON_API_VERSION, PYTHON_UNICODE_SETTING)

In most cases that will Just Work, without requiring the module writer
to modify their PyModuleDef.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:13:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 16:13:00 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273335180.7.0.124980319465.issue8084@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed test_sysconfig.py in r80986.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat May  8 18:19:29 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 16:19:29 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <4BE58B27.9000808@v.loewis.de>
Message-ID: <r2neae285401005080919ic3bd243due2a08ce7d1c6916e@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 11:02 AM, Martin v. L?wis <report at bugs.python.org> wrote:
> Did you mean to include the hunk from msg105295 as part of the patch?
> If so, wouldn't that defeat the whole point of the patch?

My intention is to offer two compilation modes to extension authors:

1) A mode that defines Py_UNICODE, PyUnicodeObject, and various unsafe
functions and macros.
2) A mode that does not define them.

In mode #1, importing the module should fail if the Unicode settings
are mismatched.  I had meant to include the hunk from msg105295 only
in mode #1.

Right now I favor your idea of generating a runtime error when loading
the module, instead of a linker error.  Assuming we go that route, the
hunk from msg105295 will not be used at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:20:37 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 08 May 2010 16:20:37 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <x2leae285401005080911uddf5bed2nc4e9b3550e453d33@mail.gmail.com>
Message-ID: <4BE58F52.1090600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> In most cases that will Just Work, without requiring the module writer
> to modify their PyModuleDef.

I'd rather modify PyModuleDef_Base, to include a flags field, and
perhaps put the api version into it, as well. That's an ABI change,
unfortunately, but such a flags field may turn out useful, anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:34:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 16:34:00 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <4BE58F52.1090600@v.loewis.de>
Message-ID: <k2seae285401005080933v4a5a7b77if6219af23ffb6aaf@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 11:20 AM, Martin v. L?wis <report at bugs.python.org> wrote:
> I'd rather modify PyModuleDef_Base, to include a flags field, and
> perhaps put the api version into it, as well. That's an ABI change,
> unfortunately, but such a flags field may turn out useful, anyway.

That works for me.  I'll work on a patch (which may end up needing
further revision, but it will at least give us a concrete basis for
further discussion).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:35:36 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 May 2010 16:35:36 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <m2reae285401005080848r8c64cb57m2b74b3001cbf1f06@mail.gmail.com>
Message-ID: <4BE592D4.9030807@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Daniel Stutzbach wrote:
> 
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
> 
> On Sat, May 8, 2010 at 10:16 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>> Are you sure this doesn't get optimized away in practice ?
> 
> I'm sure it doesn't get optimized away by gcc 4.3, where I tested it. :)
> 
>> Sure, though, I don't see how this relates to C code relying
>> on these details, e.g. a C extension will probably use different
>> conversion code depending on whether UCS2 or UCS4 is compatible
>> with some external library, etc.
> 
> Can you give an example?
> 
> All of the examples I can think of either:
> - poke into PyUnicodeObject's internals,
> - call a Python function that exposes Py_UNICODE or PyUnicodeObject
> 
> I'm explicitly trying to protect those two cases.  It's quite possible
> that I'm missing something, but I can't think of any other unsafe way
> for a C extension to convert a Python Unicode object to a byte string.

One of the more important cases you are missing is the
argument parser in Python:

Py_UNICODE *x;
Py_ssize_t y;
PyArg_ParseTuple(args, "u#", &x, &y);

This uses the native Py_UNICODE type, but doesn't rely on any
Unicode APIs.

Same for the tuple builder:

args = Py_BuildValue("(u#)", x, y);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:42:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 16:42:17 +0000
Subject: [issue8038] Provide unittest.TestCase.assertNotRegexpMatches
In-Reply-To: <1267538266.49.0.841042020206.issue8038@psf.upfronthosting.co.za>
Message-ID: <1273336937.77.0.990419368838.issue8038@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Docstrings committed revision 80990.

----------
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8038>
_______________________________________

From report at bugs.python.org  Sat May  8 18:46:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 16:46:08 +0000
Subject: [issue8636] enumerate() test cases do not cover optional start
	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1273337168.29.0.891665252992.issue8636@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80991. Thanks for the patch.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8636>
_______________________________________

From report at bugs.python.org  Sat May  8 18:47:28 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 16:47:28 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <4BE592D4.9030807@egenix.com>
Message-ID: <q2reae285401005080947qcbc2b3f0x55d1ae7559fe8d66@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 11:35 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> One of the more important cases you are missing is the
> argument parser in Python:

Thanks.  I've had my head buried in c-api/unicode.html and unicodeobject.h.

> Py_UNICODE *x;
> Py_ssize_t y;
> PyArg_ParseTuple(args, "u#", &x, &y);

My plan is to not define Py_UNICODE in Unicode-agnostic mode, to
prevent that from compiling.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 18:50:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 16:50:11 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
	Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1273337411.19.0.189734072777.issue8627@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I also have my doubts about the other 'goto error' lines in PyType_Ready, but I haven't figured out how to trigger those gotos in normal code.

Trying to figure out how to clean up properly on error in PyType_Ready is making my head hurt.

As a quick fix, we could simply do a PyErr_Clear() if the PyErr_WarnPy3k returns -1;  this clearly isn't right, but at least it gets rid of the "XXX undetected error".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8627>
_______________________________________

From report at bugs.python.org  Sat May  8 18:50:50 2010
From: report at bugs.python.org (Timothy Pederick)
Date: Sat, 08 May 2010 16:50:50 +0000
Subject: [issue8662] bytes join cannot join bytes
In-Reply-To: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>
Message-ID: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>


New submission from Timothy Pederick <pederick at gmail.com>:

This code behaves as expected:
>>> ' '.join('cat')
'c a t'

This code does not:
>>> b'\x00'.join(b'cat')
Traceback (most recent call last):
  ...
    b'\x00'.join(b'cat')
TypeError: sequence item 0: expected bytes, int found

Instead, you have to do something like this:
>>> b'\x00'.join(bytes((i,)) for i in b'cat')
b'c\x00a\x00t'

The cause is that indexing a bytes object gives an int, not a bytes. I know, it's as designed, PEP 3137, etc. But in this specific instance, it causes Python to behave inconsistently (bytes vs. str) and unintuitively (to me, anyway).

(Same problem with bytes or bytearray in either position.)

----------
files: joinerror.py
messages: 105317
nosy: perey
priority: normal
severity: normal
status: open
title: bytes join cannot join bytes
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17262/joinerror.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8662>
_______________________________________

From report at bugs.python.org  Sat May  8 19:06:56 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 17:06:56 +0000
Subject: [issue8301] Putting a function in a unittest.TestSuite doesn't work
In-Reply-To: <1270301524.85.0.299541369901.issue8301@psf.upfronthosting.co.za>
Message-ID: <1273338416.05.0.254876933768.issue8301@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 80997.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8301>
_______________________________________

From report at bugs.python.org  Sat May  8 19:08:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 17:08:21 +0000
Subject: [issue8662] bytes join cannot join bytes
In-Reply-To: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>
Message-ID: <1273338501.53.0.272929536475.issue8662@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not a very useful thing to join a single string, though.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8662>
_______________________________________

From report at bugs.python.org  Sat May  8 19:38:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 17:38:41 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Distutils fails logging characters which are not part of the "default encoding":

http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20wide%203.x/builds/1062/steps/compile/logs/stdio

[...]
  File "/home/buildbot/cpython-ucs4-nonascii-\u20ac/3.x.pitrou-ubuntu-wide/build/Lib/distutils/dir_util.py", line 67, in mkpath
    log.info("creating %s", head)
  File "/home/buildbot/cpython-ucs4-nonascii-\u20ac/3.x.pitrou-ubuntu-wide/build/Lib/distutils/log.py", line 40, in info
    self._log(INFO, msg, args)
  File "/home/buildbot/cpython-ucs4-nonascii-\u20ac/3.x.pitrou-ubuntu-wide/build/Lib/distutils/log.py", line 30, in _log
    stream.write('%s\n' % msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 81: ordinal not in range(128)
[54439 refs]

----------
assignee: tarek
components: Distutils
messages: 105320
nosy: haypo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Failed compile in a non-ASCII path
type: compile error
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sat May  8 19:50:24 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 08 May 2010 17:50:24 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273341024.37.0.0671421629743.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

In Unicode-agnostic mode, instead of leaving Py_UNICODE, PyUnicodeObject, and many functions undefined, I wonder if it would be sufficient to declare Py_UNICODE like this:

struct PY_UNICODE_TYPE;
typedef struct PY_UNICODE_TYPE Py_UNICODE;

That would allow extensions to pass opaque Py_UNICODE pointers around, but not allow them to dereference the pointers nor evaluate sizeof(Py_UNICODE).

That would make PyUnicodeObject safe, as well as PyUnicode_Encode* and several other functions (anything that doesn't manipulate individual characters, basically).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 19:55:07 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 08 May 2010 17:55:07 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273341307.89.0.649022858746.issue8654@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 20:07:01 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 08 May 2010 18:07:01 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273342021.93.0.537411843922.issue8513@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Build on the os._execvpe unittest I added in py3k r81001.  Protected functions are perfectly fine things to unittest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sat May  8 20:08:10 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 08 May 2010 18:08:10 +0000
Subject: [issue8547] unittest test discovery can fail when package under test
	is also installed globally
In-Reply-To: <1272370999.28.0.856365005412.issue8547@psf.upfronthosting.co.za>
Message-ID: <1273342090.86.0.588823836103.issue8547@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8547>
_______________________________________

From report at bugs.python.org  Sat May  8 20:33:59 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 08 May 2010 18:33:59 +0000
Subject: [issue8662] bytes join cannot join bytes
In-Reply-To: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>
Message-ID: <1273343639.22.0.724974673895.issue8662@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

While the bytes-returning-int semantics might be annoying in this case, but as you point out, Timothy, it's too late to change this.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8662>
_______________________________________

From report at bugs.python.org  Sat May  8 20:36:51 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 18:36:51 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1273343811.77.0.625785622005.issue8630@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this can qualify as a bug fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Sat May  8 20:48:12 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 08 May 2010 18:48:12 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1273344492.81.0.569956887553.issue5099@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I think your patch looks good Brett.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Sat May  8 21:21:57 2010
From: report at bugs.python.org (Timothy Pederick)
Date: Sat, 08 May 2010 19:21:57 +0000
Subject: [issue8662] bytes join cannot join bytes
In-Reply-To: <1273337450.92.0.207021309047.issue8662@psf.upfronthosting.co.za>
Message-ID: <1273346517.72.0.300920043398.issue8662@psf.upfronthosting.co.za>


Timothy Pederick <pederick at gmail.com> added the comment:

Brett: Well, I was more thinking along the lines of making join() recognise when it's been passed a bytes object, rather than changing the semantics of indexing bytes. That would be a bit overdramatic!

But if it's wontfix, it's wontfix.

Antoine: Yes, the str example was just for comparison, since the behaviour of bytes is generally supposed to be the same as str. (But I'm sure I could think of some silly examples where it could be used.) The bytes problem actually came up in code I was writing... though I later ripped it out and did it differently...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8662>
_______________________________________

From report at bugs.python.org  Sat May  8 21:35:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 08 May 2010 19:35:24 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273341024.37.0.0671421629743.issue8654@psf.upfronthosting.co.za>
Message-ID: <4BE5BCF8.4020704@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> In Unicode-agnostic mode, instead of leaving Py_UNICODE,
> PyUnicodeObject, and many functions undefined, I wonder if it would
> be sufficient to declare Py_UNICODE like this:

Sounds good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sat May  8 21:36:33 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 08 May 2010 19:36:33 +0000
Subject: [issue8664] py_compile.compile() should consistently create parent
	directory of target file
In-Reply-To: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>
Message-ID: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Currently when cfile argument of py_compile.compile() is None, then path to target file is automatically calculated and parent directory of target file is created. If the same path of target file is explicitly passed as cfile argument of py_compile.compile(), then parent directory of target file is not created automatically.
This inconsistency in behavior can be easily fixed. Fixing it also allows to simplify compileall.compile_file() function, which calls py_compile.compile() and currently needs to earlier try to create parent directory of target file.

The following example shows inconsistent behavior:

$ mkdir test
$ touch test/test.py
$ tree test
test
??? test.py

0 directories, 1 file
$ python3.2 -c 'import py_compile; py_compile.compile("test/test.py")'
$ tree test
test
??? __pycache__
?   ??? test.cpython-32.pyc
??? test.py

1 directory, 2 files
$ rm -fr test/__pycache__
$ python3.2 -c 'import py_compile; py_compile.compile("test/test.py", "test/__pycache__/test.cpython-32.pyc")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.2/py_compile.py", line 131, in compile
    with open(cfile, 'wb') as fc:
IOError: [Errno 2] No such file or directory: 'test/__pycache__/test.cpython-32.pyc'
$ mkdir test/__pycache__
$ python3.2 -c 'import py_compile; py_compile.compile("test/test.py", "test/__pycache__/test.cpython-32.pyc")'
$ tree test
test
??? __pycache__
?   ??? test.cpython-32.pyc
??? test.py

1 directory, 2 files

----------
components: Library (Lib)
messages: 105328
nosy: Arfrever
priority: normal
severity: normal
status: open
title: py_compile.compile() should consistently create parent directory of target file
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8664>
_______________________________________

From report at bugs.python.org  Sat May  8 21:38:00 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 08 May 2010 19:38:00 +0000
Subject: [issue8664] py_compile.compile() should consistently create parent
	directory of target file
In-Reply-To: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>
Message-ID: <1273347480.22.0.501922671543.issue8664@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17263/python-issue8664.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8664>
_______________________________________

From report at bugs.python.org  Sat May  8 21:39:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 19:39:08 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1273347548.08.0.242075689765.issue6507@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

disassemble_str should be private with an underscore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sat May  8 21:43:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 19:43:32 +0000
Subject: [issue8664] py_compile.compile() should consistently create parent
	directory of target file
In-Reply-To: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>
Message-ID: <1273347812.24.0.463818994614.issue8664@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> barry
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8664>
_______________________________________

From report at bugs.python.org  Sat May  8 21:46:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 May 2010 19:46:37 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273347997.5.0.701796087543.issue8084@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ronald, r80967 makes test_site fail on my machine, with the following output:

======================================================================
FAIL: test_getsitepackages (__main__.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_site.py", line 188, in test_getsitepackages
    self.assertEqual(len(dirs), 4)
AssertionError: 2 != 4

----------------------------------------------------------------------
Ran 17 tests in 0.321s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_site.py", line 333, in <module>
    test_main()
  File "Lib/test/test_site.py", line 330, in test_main
    run_unittest(HelperFunctionsTests, ImportSideEffectTests)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 1038, in run_unittest
    _run_suite(suite)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 1021, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_site.py", line 188, in test_getsitepackages
    self.assertEqual(len(dirs), 4)
AssertionError: 2 != 4

Any ideas why?  This is on a non-framework debug build of the trunk.  The variable 'dirs' turns out to be:

['Python.framework/lib/python2.7/site-packages', 'Python.framework/lib/site-python']

What else should be there?

----------
nosy: +mark.dickinson
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat May  8 21:51:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 19:51:00 +0000
Subject: [issue8665] "make pycremoval" fails
In-Reply-To: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>
Message-ID: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is probably because you remove the directory while find is walking it:

$ make pycremoval
find . -name '*.py[co]' -exec rm -f {} ';'
find . -name '__pycache__' -exec rmdir {} ';'
find: `./Lib/http/__pycache__': No such file or directory
find: `./Lib/unittest/test/__pycache__': No such file or directory
find: `./Lib/unittest/__pycache__': No such file or directory
find: `./Lib/email/__pycache__': No such file or directory
find: `./Lib/test/__pycache__': No such file or directory
find: `./Lib/importlib/__pycache__': No such file or directory
find: `./Lib/urllib/__pycache__': No such file or directory
find: `./Lib/__pycache__': No such file or directory
find: `./Lib/encodings/__pycache__': No such file or directory
find: `./Lib/json/__pycache__': No such file or directory
make: [pycremoval] Error 1 (ignored)

----------
assignee: barry
components: Build
messages: 105331
nosy: barry, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "make pycremoval" fails
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8665>
_______________________________________

From report at bugs.python.org  Sat May  8 21:53:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 19:53:05 +0000
Subject: [issue8664] py_compile.compile() should consistently create parent
	directory of target file
In-Reply-To: <1273347393.41.0.872470014027.issue8664@psf.upfronthosting.co.za>
Message-ID: <1273348385.37.0.400527898523.issue8664@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Looks good. Applied in r81005.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8664>
_______________________________________

From report at bugs.python.org  Sat May  8 21:56:35 2010
From: report at bugs.python.org (Tim Chase)
Date: Sat, 08 May 2010 19:56:35 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>


New submission from Tim Chase <python.list at tim.thechases.com>:

Patch to update ConfigParser.py so that the .get* methods can take an optional parameter rather than raising exceptions.  Usage:

  cp = ConfigParser(...)
  # ...
  value = cp.get('MySection', 'MyOption', default='some default')
  i = cp.getint('MySecton', 'MyInt', default=42)
  f = cp.getfloat('MySection', 'MyF', default=3.14)

----------
components: Library (Lib)
messages: 105333
nosy: Gumnos
priority: normal
severity: normal
status: open
title: Allow ConfigParser.get*() to take a default value
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sat May  8 22:02:09 2010
From: report at bugs.python.org (Tim Chase)
Date: Sat, 08 May 2010 20:02:09 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273348929.02.0.348508907108.issue8666@psf.upfronthosting.co.za>


Tim Chase <python.list at tim.thechases.com> added the comment:

For some reason, the diff didn't attach to the previous message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sat May  8 22:08:25 2010
From: report at bugs.python.org (Tim Chase)
Date: Sat, 08 May 2010 20:08:25 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273349305.12.0.27828603733.issue8666@psf.upfronthosting.co.za>


Tim Chase <python.list at tim.thechases.com> added the comment:

Trying a 3rd time to attach the diff (this time from Safari instead of FF)

----------
keywords: +patch
Added file: http://bugs.python.org/file17264/ConfigParser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sat May  8 22:23:25 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 08 May 2010 20:23:25 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1273350205.27.0.0941411062992.issue6507@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Done. Attached new patch as issue6507_2_priv.diff.

----------
Added file: http://bugs.python.org/file17265/issue6507_2_priv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Sat May  8 22:24:46 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 08 May 2010 20:24:46 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273350286.96.0.208098869465.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'll look into this in the morning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Sat May  8 23:07:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 08 May 2010 21:07:08 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273352828.51.0.750694274333.issue8666@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> unit test needed
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sat May  8 23:53:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 21:53:33 +0000
Subject: [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273355613.86.0.519369034252.issue8642@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Seems ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8642>
_______________________________________

From report at bugs.python.org  Sun May  9 00:04:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 22:04:07 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273356247.69.0.333313503288.issue8666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know if this feature request should be discussed on python-ideas first. Do you have real use cases for this, is it just a nice-to-have thing?

If it?s accepted, I have some remarks about the patch:
- 2.7 is feature-frozen, so you?ll need to target the py3k branch. (Do we need to put a big warning somewhere?) Practically, this means that ?ValueError, thing? should be ?ValueError(thing)?.
- Lone parens or ?):? on a line are not pretty.
- Some indentation after a linebreak do not comply with PEP?8 (e.g., do
def function(argument, argument,
             indent after parens column, end):

Thanks for your submission!

----------
nosy: +merwok
stage: unit test needed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sun May  9 00:18:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 22:18:11 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273357091.4.0.211490392306.issue8653@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think you mean http://docs.python.org/library/urlparse.html#urlparse.urlparse

Dave, perhaps you were looking at an older version? Doc fixes for maintainance branches are welcome.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Sun May  9 00:50:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 22:50:13 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <201005090042.04793.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What is your locale and your locale encoding? distutils use ASCII but I'm not 
sure that your locale encoding is ASCII, because Python fails to start if the 
locale is ASCII and the path contains a non ASCII character.

See also issue #8611: "Python3 doesn't support locale different than utf8 and 
an non-ASCII path (POSIX)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 00:50:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 22:50:23 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273327655.42.0.982773544455.issue8644@psf.upfronthosting.co.za>
Message-ID: <l2pd38f5331005081546gc3f28c68r78156c1246681ea@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 8, 2010 at 10:07 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> I definitely think this should go into 2.7 as well; ??total_seconds has only seen the light of day
> in the beta releases so far, so it's unlikely we'd break anyone's code with this change.
> ??(And IMO this is a bugfix, not a feature.)

Tracker web site seems to be down, so I am trying my luck attaching a
patch to an e-mail reply.  It did work in the past.

The true division by 10**6 could probably be replaced with division by
1e6 in the tests and docs, but I am not sure if the two are always
equivalent.

----------
Added file: http://bugs.python.org/file17266/issue8644.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________
-------------- next part --------------
Index: Misc/NEWS
===================================================================
--- Misc/NEWS	(revision 81011)
+++ Misc/NEWS	(working copy)
@@ -70,6 +70,8 @@
   inheritance with the underlying socket object. 
   The cheap inheritance has been deprecated.
 
+- Issue #8644: td.total_seconds() is now equivalent to td / timedelta(seconds=1).
+
 - Issue #4265: shutil.copyfile() was leaking file descriptors when disk fills.
   Patch by Tres Seaver.
 
@@ -200,6 +202,8 @@
 Extension Modules
 -----------------
 
+- Issue #8644: Improved accuracy of timedelta.total_seconds().
+
 - Use Clang 2.7's static analyzer to find places to clean up some code.
 
 - Build the ossaudio extension on GNU/kFreeBSD.
Index: Doc/library/datetime.rst
===================================================================
--- Doc/library/datetime.rst	(revision 81011)
+++ Doc/library/datetime.rst	(working copy)
@@ -270,9 +270,13 @@
 
 .. method:: timedelta.total_seconds()
 
-   Return the total number of seconds contained in the duration. Equivalent to
-   ``td.microseconds / 1000000 + td.seconds + td.days * 24 * 3600``.
+   Return the total number of seconds contained in the duration.
+   Equivalent to ``(td.microseconds + (td.seconds + td.days * 24 *
+   3600) * 10**6) / 10**6`` computed with true division enabled.
 
+   Note that for very large time intervals (greater than 270 years on
+   most platforms) this method will lose microsecond accuracy.
+
    .. versionadded:: 2.7
 
 
Index: Lib/test/test_datetime.py
===================================================================
--- Lib/test/test_datetime.py	(revision 81011)
+++ Lib/test/test_datetime.py	(working copy)
@@ -2,7 +2,7 @@
 
 See http://www.zope.org/Members/fdrake/DateTimeWiki/TestCases
 """
-
+from __future__ import division
 import os
 import pickle
 import cPickle
@@ -269,6 +269,13 @@
         for total_seconds in [123456.789012, -123456.789012, 0.123456, 0, 1e6]:
             td = timedelta(seconds=total_seconds)
             self.assertEqual(td.total_seconds(), total_seconds)
+        # Issue8644: Test that td.total_seconds() has the same
+        # accuracy as td / timedelta(seconds=1).
+        for ms in [-1, -2, -123]:
+            td = timedelta(microseconds=ms)
+            self.assertEqual(td.total_seconds(),
+                             ((24*3600*td.days + td.seconds)*10**6
+                              + td.microseconds)/10**6)
 
     def test_carries(self):
         t1 = timedelta(days=100,
Index: Modules/datetimemodule.c
===================================================================
--- Modules/datetimemodule.c	(revision 81011)
+++ Modules/datetimemodule.c	(working copy)
@@ -2096,9 +2096,25 @@
 static PyObject *
 delta_total_seconds(PyObject *self)
 {
-	return PyFloat_FromDouble(GET_TD_MICROSECONDS(self) / 1000000.0 +
-				  GET_TD_SECONDS(self) +
-				  GET_TD_DAYS(self) * 24.0 * 3600.0);
+	PyObject *total_seconds;
+	PyObject *total_microseconds;
+	PyObject *one_million;
+
+	total_microseconds = delta_to_microseconds((PyDateTime_Delta *)self);
+	if (total_microseconds == NULL)
+		return NULL;
+
+	one_million = PyLong_FromLong(1000000L);
+	if (one_million == NULL) {
+		Py_DECREF(total_microseconds);
+		return NULL;
+	}
+
+	total_seconds = PyNumber_TrueDivide(total_microseconds, one_million);
+
+	Py_DECREF(total_microseconds);
+	Py_DECREF(one_million);
+	return total_seconds;
 }
 
 static PyObject *

From report at bugs.python.org  Sun May  9 00:54:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 22:54:27 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273359267.78.0.230181141509.issue8644@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17266/issue8644.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sun May  9 00:56:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 May 2010 22:56:37 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273359397.69.0.164306005755.issue8644@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17267/issue8644.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sun May  9 01:03:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 23:03:23 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273359803.25.0.254854296942.issue8663@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I answered on IRC, this is on a buildbot environment. Compiling from the command line works fine, but not from the buildbot environment.

>From the command line, the locale is as following:
$ locale
LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

But I guess this information is not useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:06:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 23:06:19 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273359979.2.0.0212908546226.issue8663@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, this might be more interesting:

$ cat | ./python -i
Python 3.2a0 (py3k:81010, May  8 2010, 23:25:47) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'UTF-8'
>>> import sys
>>> sys.stdin 
<_io.TextIOWrapper name='<stdin>' encoding='ascii'>
>>> sys.getdefaultencoding()
'utf-8'

As you see, stdin uses ascii...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:14:41 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 08 May 2010 23:14:41 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273360481.12.0.55324089644.issue8666@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sun May  9 01:20:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 23:20:55 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273360855.12.0.243433411557.issue8663@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Anyway, regardless of the actual stdout encoding, distutils should be able to log messages without crashing, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:33:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 23:33:44 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273361624.98.0.612253775655.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Conditions to reproduce the bug: don't use make -j N (unset MAKEFLAGS), stdout and stderr should be be TTY => use make 2>&1|cat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:33:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 23:33:59 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273361639.15.0.495386030202.issue8663@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Another long-standing encoding bug was fixed: It was impossible to use e.g. an author name with non-ASCII characters. The fix makes distutils use UTF-8. Of course, it?s more complicated to choose an encoding for terminal I/O.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:39:39 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 08 May 2010 23:39:39 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1273361979.85.0.99652371287.issue7245@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Committed to trunk in r81012.  though as this missed 2.7beta2 its possible that will be rejected and this becomes a 3.x only feature.

I'm porting to py3k now.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sun May  9 01:40:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 23:40:02 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273362002.85.0.736337385127.issue8663@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(I wrote before I saw Victor?s reply) Does it work with PYTHONIOENDODING set to UTF-8?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:46:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 23:46:24 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273362384.88.0.801506878702.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If the standard output is not a TTY, Python uses ASCII encoding for sys.stdout: ./python -c "import sys;print(sys.stdout.encoding)"|cat => ascii.

This issue remembers me: #8533 (regrtest: use backslashreplace error handler for stdout).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:51:33 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 08 May 2010 23:51:33 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

In trying to keep importlib's docs THE place to go for links to all relevant import details, a link to PEP 3147 is needed.

----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 105351
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Link to PEP 3147 from importlib docs
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Sun May  9 01:57:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 May 2010 23:57:13 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273363033.53.0.598865579279.issue8663@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If the standard output is not a TTY, Python uses ASCII encoding for 
> sys.stdout

We could perhaps fix this too, if python-dev agrees.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 01:57:19 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 08 May 2010 23:57:19 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1273363039.24.0.946580625218.issue2090@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Sun May  9 01:58:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 08 May 2010 23:58:10 +0000
Subject: [issue7397] __import__ docs should reference importlib.import_module
In-Reply-To: <1259235199.82.0.599302527492.issue7397@psf.upfronthosting.co.za>
Message-ID: <1273363090.7.0.381534602215.issue7397@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: georg.brandl -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7397>
_______________________________________

From report at bugs.python.org  Sun May  9 01:59:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 May 2010 23:59:46 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273363186.08.0.683837530897.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch escapes non-ASCII characters of the log message using ASCII+backslashreplace (but keep unicode type).

----------
keywords: +patch
Added file: http://bugs.python.org/file17268/distutils_spawn_toascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 02:02:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 00:02:58 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273363378.36.0.523820076317.issue8663@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Wasn?t PYTHONIOENCODING added for such cases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 02:04:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 May 2010 00:04:30 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273363378.36.0.523820076317.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273363615.3250.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Wasn?t PYTHONIOENCODING added for such cases?

Yes, it was, but it's a very bad workaround. In most if not all cases,
people will set PYTHONIOENCODING to their system's default encoding.
Therefore, they shouldn't have to set an environment variable at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 02:20:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 09 May 2010 00:20:10 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273364410.52.0.890178496289.issue8666@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Sun May  9 02:48:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 May 2010 00:48:24 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273366104.84.0.300949702735.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > If the standard output is not a TTY, Python uses ASCII encoding 
> > for sys.stdout

> We could perhaps fix this too, if python-dev agrees.

Open a new issue please if you consider that as a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 02:50:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 May 2010 00:50:37 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273366237.73.0.945655640327.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried to recompile Python with "export PYTHONIOENCODING=ascii" but it doesn't fail. That's because the Makefile calls "./python -E ./setup.py -q build": -E ignores environment variables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Sun May  9 03:10:40 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 09 May 2010 01:10:40 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1273367440.18.0.757764558293.issue6526@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Did this go anywhere, David? Since beta2 just went out now is the time to either revert or enshrine the new behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Sun May  9 03:19:06 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 01:19:06 +0000
Subject: [issue8668] add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

make a 'develop' command in distutils2 a la setuptools

(unless, of course, this has already been unilaterally refused via distutils-sig or other communication)

----------
assignee: tarek
components: Distutils2
messages: 105359
nosy: meatballhat, tarek
priority: normal
severity: normal
status: open
title: add a 'develop' command
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Sun May  9 03:21:45 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 09 May 2010 01:21:45 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1273368105.56.0.35116694618.issue7245@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

And reverted in trunk r81013.  Multiple buildbot problems from the initial commit due to the unittest.

This is likely to be py3k only at this point.

I do believe sig.patch.v3 is fine, but its the test_pdb2 unittest that is difficult to make work well.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sun May  9 03:47:14 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 01:47:14 +0000
Subject: [issue8669] lack of bdist_rpm module raises error on 'setup.py
	--help-commands'
In-Reply-To: <1273369633.98.0.458470159807.issue8669@psf.upfronthosting.co.za>
Message-ID: <1273369633.98.0.458470159807.issue8669@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

Running 'python setup.py --help-commands' in the distutils2 package raises an error because there is no 'bdist_rpm' module.  Should references to 'bdist_rpm' be removed, or should the 'bdist_rpm' module be (re?)introduced?

----------
assignee: tarek
components: Distutils2
messages: 105361
nosy: meatballhat, tarek
priority: normal
severity: normal
status: open
title: lack of bdist_rpm module raises error on 'setup.py --help-commands'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8669>
_______________________________________

From report at bugs.python.org  Sun May  9 03:47:50 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 01:47:50 +0000
Subject: [issue8669] lack of bdist_rpm module raises error on 'setup.py
	--help-commands'
In-Reply-To: <1273369633.98.0.458470159807.issue8669@psf.upfronthosting.co.za>
Message-ID: <1273369670.2.0.0467827874608.issue8669@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Added file: http://bugs.python.org/file17269/distutils2-bdist-rpm-error.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8669>
_______________________________________

From report at bugs.python.org  Sun May  9 03:59:58 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 01:59:58 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273370398.41.0.652842034773.issue8324@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

For what it's worth, I'm trying to adapt the setuptools command of the same name in a feature branch called "mbh/adding-test-command" --> http://bitbucket.org/meatballhat/distutils2/

Not sure how the roundup/<external tracker> split is usually handled, so sorry if I'm doin it wrong :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 04:23:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 May 2010 02:23:46 +0000
Subject: [issue8514] Add fsencode() functions to os module
In-Reply-To: <1273332917.26.0.22174788064.issue8514@psf.upfronthosting.co.za>
Message-ID: <201005090423.39550.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why does this have no tests?

The function is trivial. Does it really need tests? What kind of tests?

fsencode() is already tested indirectly by test_subprocess, and #8513 will add 
new tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sun May  9 04:31:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 09 May 2010 02:31:39 +0000
Subject: [issue8514] Add fsencode() functions to os module
In-Reply-To: <201005090423.39550.victor.stinner@haypocalc.com>
Message-ID: <r2q1afaf6161005081931g7221ab3cg9de7c322d73b7844@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/5/8 STINNER Victor <report at bugs.python.org>:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> Why does this have no tests?
>
> The function is trivial. Does it really need tests? What kind of tests?

Check that it is equivalent to utf-8 with surrogatesescape then.

>
> fsencode() is already tested indirectly by test_subprocess, and #8513 will add
> new tests.

Excuses, excuses!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sun May  9 05:02:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 May 2010 03:02:38 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273374158.39.0.122231012032.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Build on the os._execvpe unittest I added in py3k r81001.

The test fails on Windows.

======================================================================
FAIL: test_internal_execvpe (test.test_os.ExecTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 683, in test_internal_execvpe
    exec_stubbed.calls)
AssertionError: Lists differ: [('execve', '/p/f', (['-a'], {... != [('execve', '/p\\f', (['-a'], ...

First differing element 0:
('execve', '/p/f', (['-a'], {'spam': 'beans'}))
('execve', '/p\\f', (['-a'], {'spam': 'beans'}))

- [('execve', '/p/f', (['-a'], {'spam': 'beans'})),
?                ^

+ [('execve', '/p\\f', (['-a'], {'spam': 'beans'})),
?                ^^

-  ('execve', '/pp/f', (['-a'], {'spam': 'beans'}))]
?                 ^

+  ('execve', '/pp\\f', (['-a'], {'spam': 'beans'}))]
?                 ^^

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sun May  9 05:08:14 2010
From: report at bugs.python.org (John Mark Schofield)
Date: Sun, 09 May 2010 03:08:14 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1273374494.87.0.249220974382.issue8350@psf.upfronthosting.co.za>


John Mark Schofield <jschofield at gmail.com> added the comment:

Please don't close this as "invalid."

Most (all?) of the functions in the os module have positional-only arguments, which are documented in exactly the same manner as arguments which can be supplied using a keyword.

As someone reading the documentation, how am I supposed to know which arguments can be supplied with keywords and which can't?

This ticket and the link to http://docs.python.org/dev/reference/expressions.html#calls are helpful in explaining this now, but I would NEVER have thought to look there to find out why os.fdopen isn't working the way it's documented. Requiring me to experiment to determine which function works which way seems to miss the point of having documentation in the first place.

I take no position on whether this should be fixed with a documentation change or a code change, but it should be fixed. If the consensus is that a documentation change would be quicker to implement, I'm happy to submit a doc patch.

----------
nosy: +schof

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun May  9 05:15:14 2010
From: report at bugs.python.org (John Mark Schofield)
Date: Sun, 09 May 2010 03:15:14 +0000
Subject: [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1273374914.1.0.123988995336.issue8350@psf.upfronthosting.co.za>


John Mark Schofield <jms at schof.org> added the comment:

I'd also suggest changing the title to "Documentation for many functions in os module is incomplete." I didn't because I don't know if that would be considered rude. (I'm new to the Python community.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun May  9 05:18:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 09 May 2010 03:18:12 +0000
Subject: [issue8514] Add fsencode() functions to os module
In-Reply-To: <r2q1afaf6161005081931g7221ab3cg9de7c322d73b7844@mail.gmail.com>
Message-ID: <201005090518.05888.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Check that it is equivalent to utf-8 with surrogatesescape then.

The file system encoding can be anything, not only utf-8. Anyway: r81014.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8514>
_______________________________________

From report at bugs.python.org  Sun May  9 05:30:08 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 09 May 2010 03:30:08 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1273375808.26.0.90619891198.issue8354@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Should be resolved in, oh, let's see, r81007, r81011, r81016, and r81018.  Thanks to everyone who helped out.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Sun May  9 05:37:16 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 09 May 2010 03:37:16 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273376236.46.0.295275438577.issue8513@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

my bad.  hopefully r81019 fixes that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sun May  9 06:07:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 09 May 2010 04:07:16 +0000
Subject: [issue8618] test_winsound failing on Windows Server 2008
In-Reply-To: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>
Message-ID: <1273378036.87.0.549015571356.issue8618@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Seems like this happens because there is no playback device installed. Apparently there are audio drivers install but no playback device is configured to use them.

I'm looking for a command line tool or some other way to find out details of playback devices and I'll skip the failing tests based on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8618>
_______________________________________

From report at bugs.python.org  Sun May  9 06:31:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 09 May 2010 04:31:16 +0000
Subject: [issue8618] test_winsound failing on Windows Server 2008
In-Reply-To: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>
Message-ID: <1273379476.96.0.361298387878.issue8618@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Attached is a patch which uses the multimedia mixer API to find out how many devices are known by the mixer. If none are known, 0 will be returned, and thus tests will be skipped.

----------
keywords: +patch
Added file: http://bugs.python.org/file17270/issue8618.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8618>
_______________________________________

From report at bugs.python.org  Sun May  9 06:38:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 09 May 2010 04:38:46 +0000
Subject: [issue1591035] update urlparse to RFC 3986
Message-ID: <1273379926.15.0.0096318086575.issue1591035@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is addressed and tests included as part of issue1462525.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1591035>
_______________________________________

From report at bugs.python.org  Sun May  9 08:38:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 06:38:34 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Using a UCS2 Python on a platform with a 32-bit wchar_t, the following code throws an exception (but should not):

>>> ctypes.c_wchar('\u10000')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: one character unicode string expected

The trouble is in the u_set() function in Modules/_ctypes/cfield.c.  The corresponding u_get() function looks correct.

On a UCS4 Python running on a system with a 16-bit wchar_t, u_set() will corrupt the data by silently truncating the character to 16-bits.

For reference, Linux and Mac OS use a 32-bit wchar_t while Windows uses a 16-bit wchar_t.

----------
assignee: theller
components: ctypes
messages: 105374
nosy: stutzbach, theller
priority: normal
severity: normal
stage: unit test needed
status: open
title: c_types.c_wchar should not assume that sizeof(wchar_t) == sizeof(Py_UNICODE)
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Sun May  9 11:07:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 May 2010 09:07:39 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273396059.26.0.847148709161.issue8510@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r81004: Remove extra closing bracket and comma introduced in r80969.  (This was causing misdetection of the OS X 10.5 SDK on Linux and OS X, and a test_platform failure on OS X.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Sun May  9 11:10:26 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 09 May 2010 09:10:26 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273396226.02.0.662582867326.issue8324@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Adapting the setuptools command is a great way to start of course. Please see my note about using unittest/unittest2 test discovery as a default command if unitest2 is available and no test_suite is specified. I'm very happy to help with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 11:33:01 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 09 May 2010 09:33:01 +0000
Subject: [issue8635] enumerate() docstring doesn't cover optional start
	argument
In-Reply-To: <1273151764.64.0.669433681589.issue8635@psf.upfronthosting.co.za>
Message-ID: <1273397581.31.0.27732017445.issue8635@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Attached a patch. It changes the docstring to:
"enumerate(iterable[, start]) -> iterator for index, value of iterable

Return an enumerate object.  iterable must be another object that supports
iteration, start must be an integer (defaults to 0).  The enumerate object
yields pairs containing a count (from start) and a value yielded by the
iterable argument.  enumerate is useful for obtaining an indexed list:
(0, seq[0]), (1, seq[1]), (2, seq[2]), ..."

----------
keywords: +patch
nosy: +durban
Added file: http://bugs.python.org/file17271/issue8635.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8635>
_______________________________________

From report at bugs.python.org  Sun May  9 11:36:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 May 2010 09:36:30 +0000
Subject: [issue8644] timedelta.total_seconds needlessly inaccurate,
	especially for negative timedeltas
In-Reply-To: <1273235095.12.0.903457246009.issue8644@psf.upfronthosting.co.za>
Message-ID: <1273397790.96.0.236898696246.issue8644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Perfect!  Applied in r81020.

You're correct that n/10**6 and n/1e6 aren't the same thing, at least for n large enough:

Python 2.7b2+ (trunk:81019:81020, May  9 2010, 10:33:17) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import division
[35402 refs]
>>> (2**53+1)/10**6
9007199254.740993
[35404 refs]
>>> (2**53+1)/1e6
9007199254.740992
[35404 refs]

In the second case, 2**53+1 first gets converted to a float, and then the division is performed, so there are two points at which a rounding error can be introduced.  The first case only involves one rounding error.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8644>
_______________________________________

From report at bugs.python.org  Sun May  9 13:41:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 May 2010 11:41:07 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273405267.13.0.266674073881.issue8613@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  The 'delay_traps' context manager idea doesn't quite work here.  A problem occurs if (for example) an Overflow occurs during the with block;  in that case, Overflow should be raised at the end of the with block.  That's fine, except that we no longer know what sign it should be raised with---the flags accumulated in the temporary context that's active within the with block don't remember this information.  So something more elaborate (though probably still along the same lines) would be necessary.

The decimal module has a major defect that's making this awkward, namely that there's currently no easy way to implement custom trap handling.  A custom trap handler could simply record each exception as it occurred.  IEEE 754-2008 recommends that such trap handling exists (in section 8), though the language used is "should" (i.e., is recommended to), rather than "shall" (is required to).

One simple change that might help would be to have all Decimal exceptions derive from a common `DecimalException` superclass, making it easier to catch just decimal exceptions in a try-except block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8613>
_______________________________________

From report at bugs.python.org  Sun May  9 13:45:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 May 2010 11:45:40 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273405540.58.0.46712905704.issue8613@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Umm.  Please pretend I didn't write this:

> One simple change that might help would be to have all Decimal 
> exceptions derive from a common `DecimalException` superclass, making
> it easier to catch just decimal exceptions in a try-except block.

DecimalException already exists, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8613>
_______________________________________

From report at bugs.python.org  Sun May  9 13:54:46 2010
From: report at bugs.python.org (garazi111)
Date: Sun, 09 May 2010 11:54:46 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1273406086.85.0.254231684926.issue4768@psf.upfronthosting.co.za>


garazi111 <garazi111 at yahoo.fr> added the comment:

Hi,

I think the bug is also present in the function encode_quopri which should look like this :

def encode_quopri(msg):
    """Encode the message's payload in quoted-printable.

    Also, add an appropriate Content-Transfer-Encoding header.
    """
    orig = msg.get_payload()
    encdata = _qencode(orig)
    data = str(encdata, "ASCII")
    msg.set_payload(data)
    msg['Content-Transfer-Encoding'] = 'quoted-printable'

----------
nosy: +garazi111

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Sun May  9 14:10:59 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 12:10:59 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273407059.74.0.0174336168514.issue8324@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

Should I assume that unittest2 is an installation requirement of distutils2, or is it preferable to try using unittest2 and falling back to a custom TestLoader?  Sorry if I'm reading too much into this :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:13:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 12:13:27 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273407207.95.0.565787255047.issue8324@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

unittest2 is the name of the independent release of the improved unittest package in 2.7?s and 3.2?s stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:16:37 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 12:16:37 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273407397.28.0.985465545089.issue8324@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

@merwok I know ;-)  ... should I assume that it's an installation requirement a la `install_requires=['unittest2']`, or do::

    try:
        load_tests_with_unittest2()
    except ImportError:
        load_tests_with_custom_test_loader()

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:18:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 May 2010 12:18:46 +0000
Subject: [issue8588] test_urllib2.py test failures on Py3K Mac OS X
In-Reply-To: <1272711409.24.0.121208244389.issue8588@psf.upfronthosting.co.za>
Message-ID: <1273407526.42.0.405628496702.issue8588@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r81024 (py3k), r81025 (release31-maint).

----------
components: +Library (Lib)
nosy: +mark.dickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8588>
_______________________________________

From report at bugs.python.org  Sun May  9 14:21:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 12:21:03 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273407663.8.0.542117643694.issue8324@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not a unittest expert, but I suspect that usual test for features will work:

try:
    from unittest.something.discovery import Loader
except ImportError:
    from unittest2.something.discovery import Loader

Adding Konrad to nosy, since adding new commands will be his GSoC work.

(Also adjusting versions and removing the gsoc keyword that means ?Issue is a good candidate for Google?s Summer of Code?, not ?Issue part of an accepted GSoC project?)

----------
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/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:22:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 12:22:54 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273407774.8.0.0379557459876.issue8324@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +konryd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:23:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 12:23:09 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273407789.99.0.767288437308.issue8324@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords:  -gsoc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:36:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 12:36:15 +0000
Subject: [issue8665] "make pycremoval" fails
In-Reply-To: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>
Message-ID: <1273408575.06.0.821365045815.issue8665@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Suggestion: rm -rf __pycache__ dirs before using find for stray pycs.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8665>
_______________________________________

From report at bugs.python.org  Sun May  9 14:36:58 2010
From: report at bugs.python.org (Foehn of blue)
Date: Sun, 09 May 2010 12:36:58 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273408618.98.0.998056361046.issue8613@psf.upfronthosting.co.za>


Foehn of blue <foehnofblue at kimo.com> added the comment:

Can you teach me how to Writing programs?
Please!!!
I'm from Taiwan
That's my e-mail:foehnofblue at kimo.com

----------
nosy: +foehn blue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8613>
_______________________________________

From report at bugs.python.org  Sun May  9 14:40:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 09 May 2010 12:40:18 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273408818.17.0.298201374618.issue8324@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

unittest2 is used for distutils2 development, but *not* a required dependency for *using* distutils2 (if I understand correctly(.

Well, if there is no test runner and no test suite specified but the test command is invoked then the steps should probably be something like:

* If Python version 2.7+ or 3.2+ then use test discovery from unittest
* If Python version 3.0, 3.1 or 2.6- then attempt to import unittest2 and do test discovery
* Otherwise do nothing

Test discovery is done with unittest(2).TestLoader.discover(...)

If a specific test runner or suite is provided then distutils2 should use those and need not attempt test discovery (again - my understanding).

So test discovery is a useful default if no test command is configured for a project. We may also want ways to configure that (for example allow a project to have test discovery for its test command but provide a different pattern for finding test files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:41:07 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 09 May 2010 12:41:07 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273408867.8.0.294233442654.issue8324@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Documentation for unittest.TestLoader.discover(...) is at:

http://docs.python.org/dev/library/unittest.html#unittest.TestLoader.discover

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 14:43:35 2010
From: report at bugs.python.org (bones7456)
Date: Sun, 09 May 2010 12:43:35 +0000
Subject: [issue8671] A small erorr on http://docs.python.org/library/re.html
In-Reply-To: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>
Message-ID: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>


New submission from bones7456 <bones7456 at gmail.com>:

In section \b , original text is:

Matches the empty string, but only at the beginning or end of a word. A word is defined as a sequence of alphanumeric or underscore characters, so the end of a word is indicated by whitespace or a non-alphanumeric, non-underscore character. Note that \b  is defined as the boundary between \w and \ W, so the precise set of characters deemed to be alphanumeric depends on the values of the UNICODE and LOCALE flags. Inside a character range, \b  represents the backspace character, for compatibility with Python?s string literals.

NOTE: there is space between "\" and "W", I think it is not needed.

----------
assignee: docs at python
components: Documentation
messages: 105391
nosy: bones7456, docs at python
priority: normal
severity: normal
status: open
title: A small erorr on http://docs.python.org/library/re.html
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8671>
_______________________________________

From report at bugs.python.org  Sun May  9 14:48:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 May 2010 12:48:50 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273409330.85.0.0508413530049.issue8613@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8613>
_______________________________________

From report at bugs.python.org  Sun May  9 14:50:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 12:50:29 +0000
Subject: [issue8613] Decimal module flags undetermined when a signal is
	trapped.
In-Reply-To: <1272984841.0.0.906657038884.issue8613@psf.upfronthosting.co.za>
Message-ID: <1273409429.24.0.901777514164.issue8613@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Foehn, bugs.python.org is used for discussing and solving bugs in Python, not general discussion about programming. There are Web forums and IRC rooms where your question could get answered.

I will answer you, but please do not post other unrelated messages. Try the tutorials on docs.python.org/tutorial or diveintopython3.org

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8613>
_______________________________________

From report at bugs.python.org  Sun May  9 14:54:13 2010
From: report at bugs.python.org (Dan Buch)
Date: Sun, 09 May 2010 12:54:13 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273409653.61.0.233154679045.issue8324@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

@mfoord thank you for the clarification! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 15:32:00 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 09 May 2010 13:32:00 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1273411920.05.0.0598998635187.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Let's quote RFC 3339:
"""
4.3. Unknown Local Offset Convention

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".  This differs
   semantically from an offset of "Z" or "+00:00", which imply that UTC
   is the preferred reference point for the specified time.  RFC2822
   [IMAIL-UPDATE] describes a similar convention for email.
"""

The phrase "this CAN be represented" doesn't mean that it SHOULD be represented. Do we have information to decide if offset to local zone is unknown or if UTC is the preferred reference point for specified time? I guess no, and I am afraid that most users just don't care or don't want to bog into details - all they need is a good Atom looking timestamp. As we are not aiming at making a reference library for generating all possible forms of valid RFC 3339 timestamps, it makes sense to use 'Z' in the end because it is easier to handle.

rfcformat(dt).replace("Z", "-00:00") in case somebody need a -00:00 is easier than reverse operation if you need 'Z' in the end:

dstr = rfcformat(dt)
if dstr.endswith("-00:00") or dstr.endswith("+00:00"):
    dstr = dstr[:-6] + 'Z'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Sun May  9 16:10:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 09 May 2010 14:10:03 +0000
Subject: [issue8671] A small erorr on http://docs.python.org/library/re.html
In-Reply-To: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>
Message-ID: <1273414203.3.0.906135621052.issue8671@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Fixed in:
trunk: r81026
release26-maint: r81027

It was already correct in py3k and release31-maint.

Thanks!

----------
nosy: +eric.smith
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8671>
_______________________________________

From report at bugs.python.org  Sun May  9 16:21:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 14:21:05 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1273414865.58.0.900490042169.issue6878@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attaching patch based on py3k, please review. (Mercurial diff, use patch -p1)

----------
keywords: +patch
nosy: +gpolo, merwok
stage: needs patch -> patch review
title: outdated docstring in tkinter.Canvas.coords -> changed return type from tkinter.Canvas.coords
Added file: http://bugs.python.org/file17272/fix-6878.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Sun May  9 16:32:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 14:32:46 +0000
Subject: [issue6320] Standard string encodings should include GSM0.38
In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>
Message-ID: <1273415566.58.0.358373137331.issue6320@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Are there many GSM libraries or applications out there? If not, maybe the codec is best left in your lib, since it wouldn?t be useful for a wide range of uses.

Note also that 2.7 is frozen, so substitute ?py3k branch? for ?trunk? in Antoine?s previous comment.

----------
nosy: +merwok
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6320>
_______________________________________

From report at bugs.python.org  Sun May  9 17:12:36 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 09 May 2010 15:12:36 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <q2reae285401005080947qcbc2b3f0x55d1ae7559fe8d66@mail.gmail.com>
Message-ID: <4BE6D0E0.6010602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Daniel Stutzbach wrote:
> 
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
> 
> On Sat, May 8, 2010 at 11:35 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>> One of the more important cases you are missing is the
>> argument parser in Python:
> 
> Thanks.  I've had my head buried in c-api/unicode.html and unicodeobject.h.
> 
>> Py_UNICODE *x;
>> Py_ssize_t y;
>> PyArg_ParseTuple(args, "u#", &x, &y);
> 
> My plan is to not define Py_UNICODE in Unicode-agnostic mode, to
> prevent that from compiling.
>

And later...

undefined, I wonder if it would be sufficient to declare Py_UNICODE like this:
>
> struct PY_UNICODE_TYPE;
> typedef struct PY_UNICODE_TYPE Py_UNICODE;
>
> That would allow extensions to pass opaque Py_UNICODE pointers around, but not allow them to
dereference the pointers nor evaluate sizeof(Py_UNICODE).
>
> That would make PyUnicodeObject safe, as well as PyUnicode_Encode* and several other functions
(anything that doesn't manipulate individual characters, basically).

Please make sure that these compiler tricks are portable
enough across the supported Python platforms. Just checking
with GCC 4.3 is not good enough.

I suppose you could use the buildbots to gather information
on how different compilers behave (e.g. by checking in a patch,
letting the buildbots run and then reverting it, if there's
a problem). I'm just not sure how you could check for optimization
compiler bugs/features using the buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sun May  9 17:56:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 09 May 2010 15:56:03 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1273420563.02.0.363166169789.issue7584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think Daniel's suggestion of having an option to control this is the best way to handle the different use cases.  And I think the default should be -00:00, as he suggested.

Removing 2.7 and 3.1 since 3.2 is the only branch open to new features at this point.

----------
nosy: +r.david.murray
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Sun May  9 18:32:10 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 16:32:10 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za>
Message-ID: <w2weae285401005090932n9154c001v4568b1dfab96be93@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sat, May 8, 2010 at 8:07 AM, Martin v. L??wis <report at bugs.python.org>wrote:

> 1. add a flag to PyModuleDef, indicating whether the module was built in
> UCS-2 or UCS-4 mode. Then let the interpreter refuse the load the module,
> instead of having the dynamic linker do so.

I just thought of another risk inherit in this approach.  If the extension
module is composed of more than one C file, the extension author may
inadvertently compile the file defining the PyModuleDef in Unicode-agnostic
mode but compile another file in Unicode-sensitive mode.  Then they would
have a Unicode-sensitive extension as Unicode-agnostic, which would lead to
mysterious crashes if the Unicode settings are mismatched. :-(

----------
Added file: http://bugs.python.org/file17273/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________
-------------- next part --------------
<div class="gmail_quote">On Sat, May 8, 2010 at 8:07 AM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
1. add a flag to PyModuleDef, indicating whether the module was built in UCS-2 or UCS-4 mode. Then let the interpreter refuse the load the module, instead of having the dynamic linker do so.</blockquote><div><br>I just thought of another risk inherit in this approach.?? If the extension module is composed of more than one C file, the extension author may inadvertently compile the file defining the PyModuleDef in Unicode-agnostic mode but compile another file in Unicode-sensitive mode.?? Then they would have a Unicode-sensitive extension as Unicode-agnostic, which would lead to mysterious crashes if the Unicode settings are mismatched. :-(<br>
</div></div>

From report at bugs.python.org  Sun May  9 18:42:35 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 16:42:35 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <4BE6D0E0.6010602@egenix.com>
Message-ID: <q2reae285401005090942r8c3801dbzc1368860e4341563@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Sun, May 9, 2010 at 10:12 AM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

> I'm just not sure how you could check for optimization
> compiler bugs/features using the buildbots.
>

Once I have a patch that I'm modestly confident in, I'll write automated
tests to go with it.

The tests will (at minimum):

- Create a tweaked copy of pyconfig.h that uses the opposite Unicode
settings (UCS4 v UCS2)

- Build an extension module in Unicode-agnostic mode
- Make sure it loads and works

- Build an extension module in Unicode-sensitive mode
- Make sure it doesn't load

----------
Added file: http://bugs.python.org/file17274/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________
-------------- next part --------------
<div class="gmail_quote">On Sun, May 9, 2010 at 10:12 AM, Marc-Andre Lemburg <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I&#39;m just not sure how you could check for optimization<br>
compiler bugs/features using the buildbots.<br></blockquote><div><br>Once I have a patch that I&#39;m modestly confident in, I&#39;ll write automated tests to go with it.<br><br>The tests will (at minimum):<br><br>- Create a tweaked copy of pyconfig.h that uses the opposite Unicode settings (UCS4 v UCS2)<br>
<br>- Build an extension module in Unicode-agnostic mode<br>- Make sure it loads and works<br><br>- Build an extension module in Unicode-sensitive mode<br>
- Make sure it doesn&#39;t load<br></div></div>

From report at bugs.python.org  Sun May  9 18:45:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 16:45:51 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273423551.11.0.437918181313.issue8654@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file17273/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sun May  9 18:45:55 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 16:45:55 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273423555.56.0.81370778687.issue8654@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file17274/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sun May  9 18:47:57 2010
From: report at bugs.python.org (Konrad Delong)
Date: Sun, 09 May 2010 16:47:57 +0000
Subject: [issue8312] Add post/pre hooks for distutils commands
In-Reply-To: <1270418101.32.0.698965190272.issue8312@psf.upfronthosting.co.za>
Message-ID: <1273423677.89.0.103353933511.issue8312@psf.upfronthosting.co.za>


Changes by Konrad Delong <konryd at gmail.com>:


----------
nosy: +konryd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8312>
_______________________________________

From report at bugs.python.org  Sun May  9 18:53:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 09 May 2010 16:53:49 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <w2weae285401005090932n9154c001v4568b1dfab96be93@mail.gmail.com>
Message-ID: <4BE6E89A.9000409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I just thought of another risk inherit in this approach.  If the extension
> module is composed of more than one C file, the extension author may
> inadvertently compile the file defining the PyModuleDef in Unicode-agnostic
> mode but compile another file in Unicode-sensitive mode.

I wouldn't worry about this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sun May  9 19:14:41 2010
From: report at bugs.python.org (Stuart Axon)
Date: Sun, 09 May 2010 17:14:41 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273425281.96.0.186469169324.issue4972@psf.upfronthosting.co.za>


Stuart Axon <stu.axon at gmail.com> added the comment:

It would be good for consistency, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 19:36:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 17:36:16 +0000
Subject: [issue1474680] pickling files works with protocol=2.
Message-ID: <1273426576.72.0.95560975801.issue1474680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Antoine, I think the goal here is to disable pickling, not making it work.

Alexandre, is it ok for a class to define pickle magic methods just to raise an exception? Doesn?t it break expectations?

One question hasn?t been answered: When did the protocol change? Was it intentional or is it a bug?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1474680>
_______________________________________

From report at bugs.python.org  Sun May  9 20:13:29 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 09 May 2010 18:13:29 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1273428809.65.0.966735097516.issue7584@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Here is a new patch.

The name of the optional argument is "default_utcoffset" which is obviously too long, but I can't think a better name. Any suggestions? (I think simply "utcoffset" would be misleading, because the value of the argument is only used for naive instances.)

In Modules/datetimemodule.c (in line 4375) I call Py_INCREF on the PyUnicode instance returned by PyArg_ParseTupleAndKeywords. I'm not sure this is the right thing to do. I'm doing it because the doc says that the reference count of an object returned by PyArg_ParseTupleAndKeywords shouldn't be decremented, and I think PyUnicode_AppendAndDel calls Py_XDECREF on its second argument.
Can anyone correct or confirm me on this? Thanks.

----------
Added file: http://bugs.python.org/file17275/issue7584_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Sun May  9 20:13:38 2010
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 09 May 2010 18:13:38 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1273414865.58.0.900490042169.issue6878@psf.upfronthosting.co.za>
Message-ID: <q2mac2200131005091113ub2445465gd82a487dd89e7c93@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Weird.. I was almost sure that was fixed at some point.

The patch is fine, but I would suggest adding some simple testcase(s).
This will probably require a new file (test_canvas.py) at
Lib/tkinter/test/test_tkinter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Sun May  9 20:58:35 2010
From: report at bugs.python.org (John J Lee)
Date: Sun, 09 May 2010 18:58:35 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273431515.52.0.0433722340148.issue3704@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

It looks to me that it's just request_path that's wrong, so no need to add extra arguments to that function.  It should discard the query and fragment (still keeping the "parameters" -- using urlparse.urlsplit instead of urlparse.urlparse would make that simpler).

request_path is only called in three places:

 * We're agreed that the default cookie path should omit the query (and fragment)
 * Netscape cookies aren't checked for path on setting cookies (.set_ok_path()), so the value of request_path isn't checked in that case
 * Netscape cookies are checked for path on returning cookies, but including the query & fragment will never make a difference to the .startswith check in .path_return_ok()

Finally, even RFC 2965, which nobody cares about, and which does include the path check on setting the cookie, refers to RFC 2396 for the definition of request-URI, and both RFC 2396 and RFC 3986, which obsoletes it, agree that the path doesn't include the query (nor the fragment).

Incidentally: the request_path function docstring claims to return the request-URI, but obviously the docstring should say it returns the path component of the request-URI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Sun May  9 21:02:41 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 09 May 2010 19:02:41 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273431761.87.0.339722385515.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

A patch including tests and doc changes is in attachment.

----------
versions: +Python 3.2 -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17276/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:10:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 19:10:26 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273432226.15.0.149401095666.issue4972@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Magic methods usually don?t have docstrings, since they implement one operation that is described in one place (think __len__ vs. len). You could remove the doc of __enter__ and turn the doc of __exit__ into a comment or move it to the reST file when you say that FTP supports the context management protocol.

What did you add a cmd_noop method that does the same thing as cmd_user for?

Will the change from handler to handler_instance not break third-party code?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:15:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 09 May 2010 19:15:23 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273432523.63.0.894548462376.issue8425@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Sun May  9 21:25:45 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 09 May 2010 19:25:45 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273433145.21.0.463298069236.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Magic methods usually don?t have docstrings, since they implement one 
> operation that is described in one place (think __len__ vs. len).

Agreed, I only left it since it was there in the first place.

> What did you add a cmd_noop method that does the same thing as
> cmd_user for?

Basically all DummyFTPHandler commands are no-ops except pasv, port, retr, stor and some others. There's no real reason why I added NOOP except for consistency with the FTP procol.
What I wanted to do in the new tests was just sending a command and receive a response and the "correct" way to do that in FTP is using NOOP.

> Will the change from handler to handler_instance not break 
> third-party code?

Not sure what you mean by "third party code" but it shouldn't break the existing tests if that's what you're worried about.
I did that because the original server behavior was to accept only one connection and I needed to connect more than one client in the same test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:35:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 19:35:35 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1273433145.21.0.463298069236.issue4972@psf.upfronthosting.co.za>
Message-ID: <4BE70E83.2050309@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Re-reading the patch, I notice it?s in the test module, not on the FTP
class, so I guess it?s perfectly fine. Is the string returned by a real
FTP server ?331 username ok?? (My point is that I think it would be
better to have different strings for cmd_noop and cmd_user.)

I meant code outside the standard library. I thought this was in ftplib,
but since it?s in test_ftplib we don?t have to fear breaking other
people?s code.

In summary, the diff for ftplib seems good to me, with a minor remark
about the docstrings, and I don?t feel confident enough to give a review
about the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:36:33 2010
From: report at bugs.python.org (John J Lee)
Date: Sun, 09 May 2010 19:36:33 +0000
Subject: [issue6588] insert cookies into cookie jar - cookielib.py
In-Reply-To: <1248746834.41.0.511434731236.issue6588@psf.upfronthosting.co.za>
Message-ID: <1273433793.94.0.620950502194.issue6588@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Jon,

If you want to get these changes applied you need to:

 1. Split up these three separate issues
 2. Most important: explain in full detail exactly how you used cookielib, what you expected it to do, and what it actually did, and then justify why your expectation is correct.
 3. Ensure that automated tests cover each change
 4. Respond to the review comments that are likely to follow

----------
nosy: +jjlee

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6588>
_______________________________________

From report at bugs.python.org  Sun May  9 21:39:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 19:39:46 +0000
Subject: [issue6588] insert cookies into cookie jar - cookielib.py
In-Reply-To: <1248746834.41.0.511434731236.issue6588@psf.upfronthosting.co.za>
Message-ID: <1273433986.43.0.0845964168313.issue6588@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Minor remarks:
- generate your patch from the top-level directory, so that people can just apply the patch from there (see http://www.python.org/dev/patches/);
- don?t put two statements on one line (?if thing: dostuff()?), as per PEP?8.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6588>
_______________________________________

From report at bugs.python.org  Sun May  9 21:50:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 09 May 2010 19:50:14 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273434614.99.0.192677987503.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Is the string returned by a real FTP server ?331 username ok?? (My 
> point is that I think it would be better to have different strings for 
> cmd_noop and cmd_user.)

Whoops! No that should have been "200 noop ok". 
I copied cmd_user code and forgot to modify the response string. 
Thanks.

New patch in attachment (I changed the doc a little bit including the "with" example usage in ftplib.rst other than just in what's new).

----------
Added file: http://bugs.python.org/file17277/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:50:22 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 09 May 2010 19:50:22 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273434622.72.0.834868645115.issue4972@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


Removed file: http://bugs.python.org/file17276/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:57:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 May 2010 19:57:22 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1273434614.99.0.192677987503.issue4972@psf.upfronthosting.co.za>
Message-ID: <4BE7139D.4090704@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I?m glad I had one interesting comment out of three in my first
message :)

This change, although nice, seems a bit trivial for warranting taking so
much place in the what?s new. Or perhaps it?s a good thing; I don?t know
if people are aware of the goodness of the with statement far and wide.
I?m sure amk will edit the document if he thinks the example is out of
place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sun May  9 21:57:31 2010
From: report at bugs.python.org (John J Lee)
Date: Sun, 09 May 2010 19:57:31 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1273435051.97.0.802066334819.issue5537@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Shouldn't module time be changed to use a cross-platform implementation that uses a 64 bit time_t-like type?  Apparently Perl 6 has made the equivalent change.

Admittedly there seems to be no sign of that actually happening.

----------
nosy: +jjlee

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Sun May  9 23:20:41 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 09 May 2010 21:20:41 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273357091.4.0.211490392306.issue8653@psf.upfronthosting.co.za>
Message-ID: <m2d3x4vkj8.wl%dave@boostpro.com>


Dave Abrahams <dave at boostpro.com> added the comment:

At Sat, 08 May 2010 22:18:13 +0000,
?ric Araujo wrote:
> 
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> I think you mean http://docs.python.org/library/urlparse.html#urlparse.urlparse
> 
> Dave, perhaps you were looking at an older version? Doc fixes for
> maintainance branches are welcome.

No, I was looking at (and reporting on) the docstrings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Sun May  9 23:22:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 21:22:51 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273440171.35.0.33016791811.issue8654@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file17248/unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Sun May  9 23:27:42 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 09 May 2010 21:27:42 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1273440462.34.0.108735954742.issue8324@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@Eric: I asked for the gsoc keyword to make my work easier in bug triage. And as a matter of fact, it means that the issue part of the GSoC.

----------
keywords: +gsoc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Sun May  9 23:36:22 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 09 May 2010 21:36:22 +0000
Subject: [issue4908] Implement PEP 376
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1273440982.89.0.445219267966.issue4908@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution: accepted -> duplicate
superseder:  -> Implement pkgutil APIs as described in PEP 376

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Sun May  9 23:38:06 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 09 May 2010 21:38:06 +0000
Subject: [issue4908] Implement PEP 376
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1273441086.35.0.646405926498.issue4908@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Mon May 10 00:14:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 09 May 2010 22:14:51 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1273443291.26.0.304983963221.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Here is a new patch.

Usage, short version: 

By default, modules compile in Unicode-agnostic mode, where Py_UNICODE is an incomplete type.  Unicode-agnostic modules will load in both UCS2 and UCS4 interpreters.

If a module defines PY_REAL_PY_UNICODE before including Python.h, Py_UNICODE will be a complete type.  The module can then dereference Py_UNICODE pointers and use sizeof(Py_UNICODE).  Attempting to load the module into a mismatched interpreter will cause an ImportError.

Longer version:

In Unicode-agnostic mode, extensions can pass around Py_UNICODE pointers freely, but they will get a compilation error if they attempt to dereference the pointer or use sizeof(Py_UNICODE).  In Unicode-agnostic mode, the following are never defined: Py_UNICODE_SIZE, Py_UNICODE_WIDE, HAVE_USABLE_CHAR_T, and functions and macros take Py_UNICODE as parameter or return it.

Passing a Py_UNICODE pointer to a function that expects a wchar_t * (or something similar) will compile, but will generate an incompatible pointer types warning.

Per MvL's suggestion, the patch adds a flag field to PyModuleDef_Base and defines two flags: one to indicate if the module depends on the Unicode width, and another to indicate the width the module was compiled with.  These flags are checked in PyModule_Create2.

The patch includes unit tests to ensure that importing works or doesn't work in the correct cases.

19 of the 77 modules in Modules/ needed PY_REAL_PY_UNICODE.  

18 of them failed to compile without it (good!).

1 of them (_tkinter.c) output an "incompatible pointer types" warning without it, but compiled anyway (resulting in bad code - without evidence to the contrary it assumed Python was UCS2).

I ran the test suite with a UCS2 Python and a UCS4 Python on Linux.  I had hoped to run the test suite on Windows as well, but many tests are failing on Windows even without the patch.

----------
Added file: http://bugs.python.org/file17278/unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Mon May 10 00:44:06 2010
From: report at bugs.python.org (Matthew Brett)
Date: Sun, 09 May 2010 22:44:06 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>


New submission from Matthew Brett <matthew.brett at gmail.com>:

I have a valid zlib compressed string, attached here as 'mat.bin' (1.7M), that cause and error on zlib.decompress decompression:

>>> import zlib
>>> data = open('mat.bin', 'rb').read()
>>> out = zlib.decompress(data)
Traceback (most recent call last):
  File "<ipython console>", line 1, in <module>
error: Error -5 while decompressing data

I know these data are valid, because I get the string I was expecting with:

>>> dc_obj = zlib.decompressobj()
>>> out = dc_obj.decompress(data)

As expected, there is no remaining data after this read:

>>> assert dc_obj.flush() == ''
>>> 

I believe that the behavior of zlib.decompress(data) and zlib.decompressobj().decompress(data) should be equivalent, and that the error for zlib.decompress(data) is therefore the symptom of a bug.

----------
components: IO
files: mat.bin
messages: 105420
nosy: matthew.brett
priority: normal
severity: normal
status: open
title: Error decompressing valid zlib data
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file17279/mat.bin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Mon May 10 00:49:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 May 2010 22:49:10 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273445350.93.0.652407531393.issue8672@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib) -IO
stage:  -> needs patch
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Mon May 10 01:51:39 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 09 May 2010 23:51:39 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1273449099.03.0.260341574533.issue4256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

So, is there any decision here, so that I could get down to providing better patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon May 10 01:52:22 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 09 May 2010 23:52:22 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273449141.95.0.166040614909.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Bump! Is there anything happening about this bug? Is my patch any good or should I try to work on something different?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon May 10 02:51:26 2010
From: report at bugs.python.org (Tim Chase)
Date: Mon, 10 May 2010 00:51:26 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273452686.58.0.445680195725.issue8666@psf.upfronthosting.co.za>


Tim Chase <python.list at tim.thechases.com> added the comment:

Yes, the use-case is the same as a dict.get(key, default) which I frequently use -- so it can be used in things like

  result = some_function(
     cp.get('MySection', 'MyValue', default='hello'),
     cp.getint('MySection', 'MyInt', default=42)
     )

To write something similar with the current ConfigParser requires a lot more code or an inelegant wrapper (either passing the config-parser object each call, or capturing the parser object in a closure which makes the "def" something repeated):

  try:
    mv = cp.get('MySection', 'MyValue')
  except (NoSectionError, NoOptionError), e:
    mv = 'hello'
  try:
    mi = cp.getint('MySection', 'MyInt')
  except (NoSectionError, NoOptionError), e:
    mi = 42
  result = some_function(mv, mi)
  del mv, mi  # leaving the namespace as it was before

The above can be done in a scattering of wrapper functions, but the addition in stock ConfigParser prevents a lot of duplicate code.  This is the fourth project in which I've used the ConfigParser and have reached for a default value in every one of them, to be frustrated by the lack.

The old-style "raise ValueError" you mention was the original code (just indented), but I've changed it to the preferred format.

For the dangling close-paren or "):" on its own line, I tend to do it for the same reason a trailing comma is allowed/encouraged in lists/tuples/dicts/param lists, so it's easy to add further comma-separated entries without giving cluttered diffs.  The source against which I'm patching has several dangling close-parens already (search for "^\s*)" to find the calls to re.compile).

I pulled down the branches/py3k and patched against it. (attached)

----------
Added file: http://bugs.python.org/file17280/configparser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Mon May 10 06:26:18 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 10 May 2010 04:26:18 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273465578.59.0.58717664908.issue3704@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

As long as we don't care about preserving backward compatibility, we
could indeed just change the behavior of 'request_path'.  It isn't
documented as an API of the cookielib module, but it does have a
docstring which promises certain semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Mon May 10 08:43:27 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 10 May 2010 06:43:27 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1273449099.03.0.260341574533.issue4256@psf.upfronthosting.co.za>
Message-ID: <h2jd11dcfba1005092343j428d4cbfw1869b0a99066e376@mail.gmail.com>


Steven Bethard <steven.bethard at gmail.com> added the comment:

2010/5/9 Filip Gruszczy?ski <report at bugs.python.org>:
> So, is there any decision here, so that I could get down to providing better patch?

I guess I'd like to hear from someone about how these things work in
zsh. If we're going to add a hidden flag to *all* parsers, we should
really make sure it's compatible/useful for as many of the shells that
support this kind of autocomplete as possible...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon May 10 12:12:19 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 10 May 2010 10:12:19 +0000
Subject: [issue8673] configure script doesn't recognize 10.5 SDK correctly
In-Reply-To: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>
Message-ID: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I got a build error when building the 2.7b2 installers because the MacOS module couldn't be build. That turns out to be caused by an issue in the configure script: for some reason the check for the 10.5 SDK gives the wrong answer (both with and without building using the 10.4u SDK).

I haven't had time to research the issue and worked around it by hardcoding the right answer in the configure script during my build, but that's obviously not the correct solution.

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 105426
nosy: ronaldoussoren
priority: high
severity: normal
stage: needs patch
status: open
title: configure script doesn't recognize 10.5 SDK correctly
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8673>
_______________________________________

From report at bugs.python.org  Mon May 10 12:21:20 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 10 May 2010 10:21:20 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273486880.89.0.838159406536.issue8510@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

I don't have access to source so my comment will be based only on diffs from above mentioned revisions.
r80969:
- AC_LANG_PROGRAM ... with main function in body . It is legal as I don't know C compiler that fail to compile code like ...int main() { int main() {...} ...} but is better to left body empty. Counted three times. All those cases tests for compiler flags and I think that AC_LANG_SOURCE is enough.

- body include  #include "confdefs.h" - may be buggy (before) and now AC_LANG_PROGRAM will add all defines. Counted any times. I think that is save to remove  #include "confdefs.h" from all those test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Mon May 10 13:23:48 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 10 May 2010 11:23:48 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1273490628.45.0.578354071563.issue8577@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Hmm, this issue was fixed before.
My be restore of 2.6 distutils ignore those fixes. It is good to compare current Lib/distutils/sysconfig.py with version from Dec 2009 .

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Mon May 10 13:29:11 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 10 May 2010 11:29:11 +0000
Subject: [issue8577] test_distutils fails if srcdir != builddir
In-Reply-To: <1272624004.08.0.551087353852.issue8577@psf.upfronthosting.co.za>
Message-ID: <1273490951.42.0.370730879406.issue8577@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I intend to forward port the fix to 3.2 in the near future, to avoid missing real issues when I do updates to the platform support for OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8577>
_______________________________________

From report at bugs.python.org  Mon May 10 13:32:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 11:32:38 +0000
Subject: [issue8673] configure script doesn't recognize 10.5 SDK correctly
In-Reply-To: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>
Message-ID: <1273491158.9.0.914564193305.issue8673@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this was fixed in r80969, but confirmation would be good.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8673>
_______________________________________

From report at bugs.python.org  Mon May 10 13:33:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 11:33:07 +0000
Subject: [issue8673] configure script doesn't recognize 10.5 SDK correctly
In-Reply-To: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>
Message-ID: <1273491187.9.0.358867281138.issue8673@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry;  r81004, rather.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8673>
_______________________________________

From report at bugs.python.org  Mon May 10 13:39:19 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 10 May 2010 11:39:19 +0000
Subject: [issue8673] configure script doesn't recognize 10.5 SDK correctly
In-Reply-To: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>
Message-ID: <1273491559.57.0.208566745279.issue8673@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Cool, thanks. I'll check this later this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8673>
_______________________________________

From report at bugs.python.org  Mon May 10 14:18:37 2010
From: report at bugs.python.org (Andrej Krpic)
Date: Mon, 10 May 2010 12:18:37 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1273493917.99.0.584274868873.issue7879@psf.upfronthosting.co.za>


Changes by Andrej Krpic <akrpic77 at gmail.com>:


----------
components: +Windows
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Mon May 10 14:57:15 2010
From: report at bugs.python.org (John J Lee)
Date: Mon, 10 May 2010 12:57:15 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273496235.94.0.166550220752.issue3704@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

I'll upload a patch when I'm back home (bugs.python.org went down yesterday).

Will turn docstring into comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Mon May 10 15:43:29 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Mon, 10 May 2010 13:43:29 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>


New submission from Tomas Hoger <thoger at redhat.com>:

SVN commit r64114 added integer overflow checks to multiple modules.  Checks added to audioop module are incorrect and can still be bypassed:

http://svn.python.org/view/python/trunk/Modules/audioop.c?r1=64114&r2=64113

- audioop_tostereo - should be fine, but relies on undefined behaviour
- audioop_lin2lin - undetected overflow: size=1, size2=4, len=0x40000001
- audioop_ratecv - undetected overflow: nchannels=0x5fffffff (32bit)
- audioop_ulaw2lin - undetected overflow: size=4, len=0x40000001
- audioop_alaw2lin - same as audioop_ulaw2lin
- audioop_adpcm2lin - undetected overflow: size=4, len=0x20000001

Most of these are triggered by large fragment as an input.

Attached patch replaces checks added in r64114 by checks using INT_MAX.

----------
components: Extension Modules
files: python2.6-audioop-int-overflows.diff
keywords: patch
messages: 105434
nosy: thoger
priority: normal
severity: normal
status: open
title: audioop: incorrect integer overflow checks
type: security
versions: Python 2.6
Added file: http://bugs.python.org/file17281/python2.6-audioop-int-overflows.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Mon May 10 16:15:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 May 2010 14:15:38 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273500938.64.0.470493960498.issue8256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor, you've been dealing with Python's default encoding lately, care to render an opinion on the correct fix for this bug?

@Filip: the patch will need a unit test, which will also help with assessing the validity of the fix.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon May 10 16:19:16 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 10 May 2010 14:19:16 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273501156.15.0.472508841913.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

I'll try to code a small test this evening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon May 10 16:40:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 10 May 2010 14:40:45 +0000
Subject: [issue8618] test_winsound fails when no playback devices configured
In-Reply-To: <1273019000.91.0.843326391671.issue8618@psf.upfronthosting.co.za>
Message-ID: <1273502445.99.0.289190772241.issue8618@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: test_winsound failing on Windows Server 2008 -> test_winsound fails when no playback devices configured

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8618>
_______________________________________

From report at bugs.python.org  Mon May 10 16:44:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 14:44:40 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273502680.59.0.675628813789.issue8674@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch.  I agree that undefined behaviour (e.g., from signed overflow) should be avoided where at all possible.

Do you have any Python examples that failed to trigger the overflow on your platform?  If so, it would be useful to add them to Lib/test/test_audioop.py as extra testcases.

One other question:  is there something about the formats that audioop is dealing with that limits sizes to INT_MAX (rather than PY_SSIZE_T_MAX, for example)?  I'm not really familiar with audio formats.

As an aside, I also find it strange that the code raises MemoryError in these cases, since these exceptions can be raised even when there's plenty of memory available.  IMO MemoryError should only be raised as a result of a failed attempt to allocate memory from the system.  Some other exception---perhaps OverflowError---would seem more appropriate here.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Mon May 10 16:48:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 14:48:08 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273502888.7.0.647896941889.issue8674@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unless you have an explicit exploit, I think the 'type' should be 'behavior' rather than 'security'.

----------
stage:  -> unit test needed
type: security -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Mon May 10 16:54:23 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 May 2010 14:54:23 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273503263.74.0.606289623103.issue8256@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is wrong: _PyUnicode_AsString(Py_None) should not return "utf8"!

I suggest that since PyOS_Readline() write the prompt to stderr, the conversion uses the encoding of stderr.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Mon May 10 17:00:58 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 May 2010 15:00:58 +0000
Subject: [issue4972] let's equip ftplib.FTP with __enter__ and __exit__
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1273503658.54.0.588854923816.issue4972@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This is now committed as r81041.
I've also removed the long description from what's new file, as you were suggesting.

The other two patches should be adapted for 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Mon May 10 17:05:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 15:05:17 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273503917.06.0.595395323764.issue8674@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, it looks to me as though all those 'int' lengths should really be 'Py_ssize_t'.  I don't think that's something we can change in 2.6, though;  probably not in 2.7 either, since we're getting too close to the release.  It can and should be changed in py3k, though.

I'll review this patch and (assuming it looks good) apply it to the 2.x branches.  It would be great to have some tests, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Mon May 10 17:08:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 May 2010 15:08:34 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1273504114.71.0.0236531706199.issue4256@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

zsh's completion system is completely programmable.  I looks like it would be pretty easy to add generic 'python script' support widgets(*) using this hidden option, and probably other neat tricks as well.  Something that would make it even more useful for zsh completion would be to include information on the type of the argument when known.  A zsh completer could then be programmed to do smart completion on the option value as well.

(*) You can write a 'widget' and assign it to a key, and then when you use that key the completion widget (shell function) is called and could run the command with the hidden option to get the option info and generate the completion list.  That's just the *easiest* way to integrate support for this into zsh completion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Mon May 10 17:21:35 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Mon, 10 May 2010 15:21:35 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273504895.42.0.775977214562.issue8674@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

> Do you have any Python examples that failed to trigger the overflow
> on your platform?

No, I've not really tried to create some, as I found it while looking into similar checks added to rgbimg module (which is dead and removed upstream now) in the same commit r64114.

Having another close look, I can reproduce crash with lin2lin:
  audioop.lin2lin("A"*0x40000001, 1, 4)

ratecv may cause issues too.  Other cases use for loop with multiplication product as an upper bound, so the integer overflow should be harmless in those case.

> is there something about the formats that audioop is dealing
> with that limits sizes to INT_MAX (rather than PY_SSIZE_T_MAX,
> for example)?

I've started looking into this on oldish python 2.4, where PyString_FromStringAndSize accepts int size, rather than Py_ssize_t.  Rest of the audioop code was using ints too.  It's possible it is ok to more to size_t in current python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Mon May 10 17:44:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 May 2010 15:44:11 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1273506251.19.0.270003927129.issue8490@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r81043 (trunk) and r81044 (3.2).
Thanks for your comments.

----------
assignee: josiahcarlson -> giampaolo.rodola
components: +Tests
resolution:  -> fixed
stage:  -> committed/rejected
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Mon May 10 17:45:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 May 2010 15:45:07 +0000
Subject: [issue8490] asyncore test suite
In-Reply-To: <1271878441.03.0.198922650318.issue8490@psf.upfronthosting.co.za>
Message-ID: <1273506307.47.0.672607470947.issue8490@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8490>
_______________________________________

From report at bugs.python.org  Mon May 10 17:57:44 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 May 2010 15:57:44 +0000
Subject: [issue7040] test_smtplib fails on os x 10.6
In-Reply-To: <1254515914.47.0.694071421893.issue7040@psf.upfronthosting.co.za>
Message-ID: <1273507064.34.0.942887183435.issue7040@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Closed as duplicate of issue7037.

----------
nosy: +giampaolo.rodola
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7040>
_______________________________________

From report at bugs.python.org  Mon May 10 18:21:09 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 10 May 2010 16:21:09 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273508469.42.0.552360208688.issue8666@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

what is this "raise_on_bad" additional argument?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Mon May 10 18:31:35 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 10 May 2010 16:31:35 +0000
Subject: [issue2982] more tests for pyexpat
In-Reply-To: <1211905628.44.0.670797216201.issue2982@psf.upfronthosting.co.za>
Message-ID: <1273509095.4.0.503211680051.issue2982@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm not a xml* modules user but I've tried to apply the patch against the trunk and it seems it still works.

----------
nosy: +effbot, giampaolo.rodola, loewis
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2982>
_______________________________________

From report at bugs.python.org  Mon May 10 19:05:12 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 10 May 2010 17:05:12 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273511112.31.0.571386227803.issue1285086@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

I can only reiterate that Zope apps can call 'urllib.quote' dozens,
hundreds, even thousands of times on a single request:  the
reason for the original bug report was that 'urllib.quote' was
showing up frequently on profiling output for such requests.
Short-circuiting the case for the empty string and the case that
the string being quoted actually contains only safe characters
together made 'urllib.quote' disappear from the profiler output.

Newer frameworks, such as 'repoze.bfg', avoid using
'urliib.quote' at all for just this reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Mon May 10 19:16:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 17:16:40 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273511800.66.0.350264269962.issue8674@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, writing portable tests turns out to be tricky;  I also don't want to write tests based on int that'll fail when/if Py_ssize_t is substituted.

Applied the patch (with a couple of minor changes) in r81045 through r81048.  I'll open another issue for the int->Py_ssize_t changes.

Thanks again for the patch!

----------
assignee:  -> mark.dickinson
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Mon May 10 19:44:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 May 2010 17:44:37 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1273432523.79.0.0658499297918.issue8425@psf.upfronthosting.co.za>
Message-ID: <AANLkTilSTXfXChxQwwd9Ko5mQUwApt5_p_SB3rvVHg3P@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The problem is apparently due to the fact that small_set -= large_set
iterates over the large set removing entries from small_set while more
efficient small_set - large_set builds a new set iterating over a
small_set and adding items that are not in the large set.  Since
lookups are O(1), it is more efficient to iterate over a small set
while looking up a large set than the other way around.  I am
attaching a minimalist patch which gives up in-place update for s1 -=
s2 if len(s1) < len(s2) and effectively replaces it with s1 = s1 - s2.
 The code can be further optimized by replicating set_difference logic
in set_isub instead of relying on fall back behavior, but the big
question here  with whether it is acceptable to give up preserving set
identity in in-place subtract to gain performance.

----------
keywords: +patch
Added file: http://bugs.python.org/file17282/issue8425.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________
-------------- next part --------------
Index: Objects/setobject.c
===================================================================
--- Objects/setobject.c	(revision 81048)
+++ Objects/setobject.c	(working copy)
@@ -1612,7 +1612,10 @@
 static PyObject *
 set_isub(PySetObject *so, PyObject *other)
 {
-    if (!PyAnySet_Check(other)) {
+    if (!PyAnySet_Check(other) ||
+	/* Fall back to s = s - o if len(s) < len(o) to
+	   avoid interation over a large set. */
+	PySet_GET_SIZE(so) < PySet_GET_SIZE(other)) {
         Py_INCREF(Py_NotImplemented);
         return Py_NotImplemented;
     }

From report at bugs.python.org  Mon May 10 19:46:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 May 2010 17:46:29 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273513589.0.0.699764244042.issue8425@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon May 10 20:07:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 May 2010 18:07:42 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273514862.87.0.69801742255.issue8425@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The answer is almost certainly "no".

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon May 10 20:13:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 May 2010 18:13:08 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273515188.77.0.393124731621.issue8425@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second thought, it is possible to preserve set identity and avoid iteration over a large set.   See issue8425a.diff attached.

It looks like the unit tests don't check identity preservation.  I will submit additional tests shortly.

----------
Added file: http://bugs.python.org/file17283/issue8425a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon May 10 20:16:38 2010
From: report at bugs.python.org (Tim Chase)
Date: Mon, 10 May 2010 18:16:38 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273515398.49.0.185671560154.issue8666@psf.upfronthosting.co.za>


Tim Chase <python.list at tim.thechases.com> added the comment:

The "raise_on_bad" (I'm ambivalent on the name, but if you come up with a better name, I'd be fine with changing it) allows you to differentiate between an option that isn't provided, and one that is provided, but can't be converted to the specified int/float/boolean type.  E.g.

  [MySection]
  myFloat = hello

if you issue

  f = cp.getfloat("MySection", "myFloat", default=3.14, raise_on_bad=True)

it will raise a ValueError because "hello" can't be converted to a float.  However there are other times you want (well, other times *I've* wanted...most cases, in fact) to be able to specify that if there's ANY problem, just return the default:

  f = cp.getfloat("MySection", "myFloat", default=3.14, raise_on_bad=False)

returns f=3.14 (the default).  The only crazy side-exception I saw in the code is if you make a "dumb programmer" mistake of 

  f = cp.getfloat("MySection", "myFloat", default="foo", raise_on_bad=False)

it may still give you an error or unexpected non-float results because the default isn't what you asked for.

The ability to get a valid result back (regardless of section or option presence; or data errors) is most helpful when all you want is the answer to the question "did the user specify a valid value I can use? otherwise, just use the darn default".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Mon May 10 20:27:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 May 2010 18:27:55 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273516075.89.0.454130438457.issue8425@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17284/issue8425-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon May 10 20:38:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 May 2010 18:38:05 +0000
Subject: [issue8675] audioop module needs an int -> Py_ssize_t upgrade
In-Reply-To: <1273516685.47.0.439722259241.issue8675@psf.upfronthosting.co.za>
Message-ID: <1273516685.47.0.439722259241.issue8675@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The audioop module still uses 'int' for most of its sizes;  it would be better if it used 'Py_ssize_t' instead, so that data aren't artificially limited to 2Gb on 64-bit systems.

Converting ought to be a fairly straightforward task for someone wanting to get their feet wet with CPython hacking;  marking as easy.

----------
keywords: easy
messages: 105454
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: audioop module needs an int -> Py_ssize_t upgrade
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8675>
_______________________________________

From report at bugs.python.org  Mon May 10 20:51:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 May 2010 18:51:24 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273517484.93.0.347291477114.issue8425@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that issue8425a.diff leaves small_set.difference_update(large_dict) unoptimized:

$ ./python.exe -m timeit -s "s = {1}; l = dict.fromkeys(range(1000));" "s.difference_update(l)"
1000 loops, best of 3: 842 usec per loop
$ ./python.exe -m timeit -s "s = {1}; l = dict.fromkeys(range(1000));" "s.difference(l)"
100000 loops, best of 3: 13.2 usec per loop

It would be easy to add an extra type check, but I noticed that small_set.difference_update(large_dict.viewkeys()) is not optimized either:

$ ./python.exe -m timeit -s "s = {1}; l = dict.fromkeys(range(1000));" "s.difference(l.viewkeys())"
1000 loops, best of 3: 842 usec per loop

It would be nice if there was a uniform C-API that would allow to uniformly check that an object supports O(1) lookup and invoke such lookup efficiently.  I don't think such C-API exists at the moment.

I would like to hear what others have to say before adding optimizations  to the patch that go beyond the scope of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Mon May 10 21:06:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 May 2010 19:06:51 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1273518411.93.0.197966310759.issue4768@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Mon May 10 21:26:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 May 2010 19:26:01 +0000
Subject: [issue8666] Allow ConfigParser.get*() to take a default value
In-Reply-To: <1273348594.74.0.554904911988.issue8666@psf.upfronthosting.co.za>
Message-ID: <1273519561.51.0.527977903614.issue8666@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Rather than a raise_on_bad option, it seems to me it would be better to code a try/except clause in cases where you want the default even if there is an error converting the data in the file.  I would expect such cases to be rare, except for cases where you want to issue a warning message and then proceed with the default anyway, in which case you'd need the try/except anyway in order to issue the warning message.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8666>
_______________________________________

From report at bugs.python.org  Mon May 10 21:29:08 2010
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 10 May 2010 19:29:08 +0000
Subject: [issue8676] Py3k Built-in Exceptions documentation mentions the raise
	statement of 2.x
In-Reply-To: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>
Message-ID: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

In the documentation of the exceptions (http://docs.python.org/dev/py3k/library/exceptions) there is a sentence:
"The associated value is the second argument to the raise statement."
But in py3k there is a different raise statement than in 2.x.

----------
assignee: docs at python
components: Documentation
messages: 105457
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Py3k Built-in Exceptions documentation mentions the raise statement of 2.x
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8676>
_______________________________________

From report at bugs.python.org  Mon May 10 21:39:56 2010
From: report at bugs.python.org (John J Lee)
Date: Mon, 10 May 2010 19:39:56 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273520396.45.0.452072133267.issue3704@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Just re-read your comment, Tres.  Since when do docstrings determine whether a stdlib function is public?  If it's documented in the docs, it's public.  If not, it's not.  This function isn't, so it's not public.  It's also not in __all__, FWLTW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Mon May 10 21:44:50 2010
From: report at bugs.python.org (John J Lee)
Date: Mon, 10 May 2010 19:44:50 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273520690.66.0.306828369478.issue3704@psf.upfronthosting.co.za>


Changes by John J Lee <jjlee at users.sourceforge.net>:


Added file: http://bugs.python.org/file17285/issue3704.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Mon May 10 21:45:30 2010
From: report at bugs.python.org (John J Lee)
Date: Mon, 10 May 2010 19:45:30 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273520730.59.0.25183707423.issue3704@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Didn't bother changing docstring to comment, since that would be inconsistent with rest of module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Mon May 10 21:54:04 2010
From: report at bugs.python.org (John J Lee)
Date: Mon, 10 May 2010 19:54:04 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273521244.12.0.262477770052.issue3704@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

FWIW, the "certain semantics" that request_path "promises" are 1. that it returns the RFC 2965 request-URI (which has never been true -- it returns the path component of the request-URI instead) and 2. that that request-URI is as defined in RFC 2965, and this bug is about fixing the function so that that's true for the case where the URI has a query component.  So there's absolutely no reason for not changing the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Mon May 10 21:59:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 19:59:40 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a list of extension modules making use of one of the "#" format codes ("s#", "y#", etc.) without defining PY_SSIZE_T_CLEAN, and therefore being 64-bit unclean:

Modules/audioop.c
Modules/_cursesmodule.c
Modules/_elementtree.c
Modules/_gdbmmodule.c
Modules/nismodule.c
Modules/ossaudiodev.c
Modules/pyexpat.c
Modules/socketmodule.c
Modules/_ssl.c
Modules/unicodedata.c

----------
components: Extension Modules
messages: 105461
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Modules needing PY_SSIZE_T_CLEAN
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Mon May 10 22:00:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 20:00:39 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273521639.7.0.0868684887921.issue8677@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +audioop module needs an int -> Py_ssize_t upgrade
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Mon May 10 22:09:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 20:09:02 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273522142.25.0.783400382637.issue8677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The documentation says that sometimes in the future Py_ssize_t will be the default, so we may also need some kind of transition period for non-complying third-party extensions; first with warnings and then with errors perhaps.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Mon May 10 22:22:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 10 May 2010 20:22:36 +0000
Subject: [issue8303] python -m unittest -h and python -m unittest discover -h
	message slightly incorrect
In-Reply-To: <1270306453.69.0.686553855544.issue8303@psf.upfronthosting.co.za>
Message-ID: <1273522956.62.0.140147806944.issue8303@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 81055.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8303>
_______________________________________

From report at bugs.python.org  Mon May 10 22:23:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 10 May 2010 20:23:30 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273523010.72.0.521283637272.issue8677@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I personally don't think that a transition period would be a useful thing to have, in particular not if it goes like this:
- in version A, require use of PY_SSIZE_T_CLEAN
- in version A+1, make use of PY_SSIZE_T_CLEAN redundant

So I'd rather drop PY_SSIZE_T clean altogether from 3.2, and risk any breakage that this may cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Mon May 10 22:45:29 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 10 May 2010 20:45:29 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273524329.41.0.981649430579.issue8677@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Mon May 10 22:49:43 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 May 2010 20:49:43 +0000
Subject: [issue8676] Py3k Built-in Exceptions documentation mentions the raise
	statement of 2.x
In-Reply-To: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>
Message-ID: <1273524583.85.0.349916595434.issue8676@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report. Fixed in r81057.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8676>
_______________________________________

From report at bugs.python.org  Mon May 10 23:03:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 10 May 2010 21:03:02 +0000
Subject: [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273525382.94.0.522897028554.issue8642@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r81059.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8642>
_______________________________________

From report at bugs.python.org  Mon May 10 23:24:03 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 May 2010 21:24:03 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Red Hat found some crashers in the rgbimg module along with a proposed patch: https://bugzilla.redhat.com/show_bug.cgi?id=541698 . Since the patch was sent to the PSRT privately before the bugs were announced, it should be fine to take the patch from the page and apply it.

----------
messages: 105467
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: crashers in rgbimg
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Mon May 10 23:39:33 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 10 May 2010 21:39:33 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

write a script that converts a distutils or setuptools based setup.py script into a distutils2 one.

This script will need to parse the AST and generate a new setup.py, using a few transformation rules.

----------
assignee: tarek
components: Distutils2
messages: 105468
nosy: tarek
priority: normal
severity: normal
status: open
title: write a distutils to distutils2 converter
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Mon May 10 23:44:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 10 May 2010 21:44:20 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273527860.86.0.326109276773.issue8678@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a security fix, it probably applies to 2.5 and 2.6 as well.

----------
nosy: +loewis
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Tue May 11 00:11:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 22:11:03 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273529463.73.0.031151053087.issue8672@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After a bit of debugging, it seems your data is not actually a complete zlib stream (*). What did you generate it with?

(*) in technical terms, the zlib never returns Z_STREAM_END when decompressing your data. The decompressobj ignores it, but the top-level decompress() function considers it an error.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 00:15:48 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 10 May 2010 22:15:48 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Add a sandbox in distutils2, so all installation steps can be recorded or controlled.

Usage example: a dry-run mode that prevents anything to be written on the disk but just reports.

See setuptools.sandbox for example

----------
assignee: tarek
components: Distutils2
messages: 105471
nosy: tarek
priority: normal
severity: normal
status: open
title: Add a sandbox in Distutils2
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Tue May 11 00:19:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 10 May 2010 22:19:01 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1273529941.55.0.445091019479.issue8679@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

lib2to3 can be used as a framework for this feature

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Tue May 11 00:30:11 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 10 May 2010 22:30:11 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1273530611.57.0.833216984478.issue7833@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The bdist_wininst and DLL build issues also exist in Python 2.7b2. A patch against svn trunk is attached. 

The pywin32 v214 package fails as reported earlier when built with Python 2.7b2. It installs and functions when built with this patch.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file17286/msvc9compiler_stripruntimes_trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Tue May 11 00:30:58 2010
From: report at bugs.python.org (Matthew Brett)
Date: Mon, 10 May 2010 22:30:58 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273529463.73.0.031151053087.issue8672@psf.upfronthosting.co.za>
Message-ID: <AANLkTilQvgCGHDf7hkmstkcqvNpatJXjp6B-shd_H4_1@mail.gmail.com>


Matthew Brett <matthew.brett at gmail.com> added the comment:

Hi,

> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> After a bit of debugging, it seems your data is not actually a complete zlib stream (*). What did you generate it with?
>
> (*) in technical terms, the zlib never returns Z_STREAM_END when decompressing your data. The decompressobj ignores it, but the top-level decompress() function considers it an error.

Thanks for the debugging.  The stream comes from within a matlab 'mat'
file.  I maintain the scipy matlab file readers; the variables within
these files are zlib compressed streams.

 Is there (should there be) a safe and maintained way to allow me to
read a stream that does not return Z_STREAM_END?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 00:36:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 22:36:10 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <AANLkTilQvgCGHDf7hkmstkcqvNpatJXjp6B-shd_H4_1@mail.gmail.com>
Message-ID: <1273531116.23499.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thanks for the debugging.  The stream comes from within a matlab 'mat'
> file.  I maintain the scipy matlab file readers; the variables within
> these files are zlib compressed streams.

So this would be a Matlab issue, right?

>  Is there (should there be) a safe and maintained way to allow me to
> read a stream that does not return Z_STREAM_END?

Decompressor objects allow you to do that, but I cannot tell you how
"maintained" it is. If it has to be maintained, we could add an unit
test for it so that regressions get detected. It would be nice if you
could provide a very short zlib stream reproducing the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 00:37:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 22:37:40 +0000
Subject: [issue8681] Make the zlib module emit more detailed error messages
In-Reply-To: <1273531059.62.0.905439523154.issue8681@psf.upfronthosting.co.za>
Message-ID: <1273531059.62.0.905439523154.issue8681@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a patch to use our own error descriptions when the zlib doesn't provide anything in particular. It would have made issue8672 easier to diagnose for the reporter (and for us).

----------
components: Extension Modules
files: zliberrors.patch
keywords: patch
messages: 105476
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Make the zlib module emit more detailed error messages
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17287/zliberrors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8681>
_______________________________________

From report at bugs.python.org  Tue May 11 00:39:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 22:39:51 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273531191.51.0.0411280708771.issue8672@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I also think we should improve the zlib module's error messages. I've added a patch in issue8681 for that. With that patch, the message you'd've encountered would have been "Error -5 while decompressing data: incomplete or truncated stream", which is quite more informative.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 00:48:40 2010
From: report at bugs.python.org (Matthew Brett)
Date: Mon, 10 May 2010 22:48:40 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273531116.23499.4.camel@localhost.localdomain>
Message-ID: <AANLkTik5JtUFNcU1A5qDRReex-ToRt7-_uJH94L-e_Z3@mail.gmail.com>


Matthew Brett <matthew.brett at gmail.com> added the comment:

>> Thanks for the debugging. ?The stream comes from within a matlab 'mat'
>> file. ?I maintain the scipy matlab file readers; the variables within
>> these files are zlib compressed streams.
>
> So this would be a Matlab issue, right?

Yes, except scipy and numpy aim in part to be an open-source
replacement for matlab, so we very much want to be able to read their
files.

>> ?Is there (should there be) a safe and maintained way to allow me to
>> read a stream that does not return Z_STREAM_END?
>
> Decompressor objects allow you to do that, but I cannot tell you how
> "maintained" it is. If it has to be maintained, we could add an unit
> test for it so that regressions get detected. It would be nice if you
> could provide a very short zlib stream reproducing the issue

This is the only .mat file stream I have yet come across that causes
the error.  It is possible to knock a portion off the end of a valid
stream to reproduce the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 00:58:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 22:58:37 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1273532317.96.0.332493110534.issue8550@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I uploaded the latest patch at http://codereview.appspot.com/1124044

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Tue May 11 01:00:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 23:00:33 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273532433.33.0.369150717002.issue8672@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, it turned out to be quite easy indeed. Here is a patch adding a test.

----------
keywords: +patch
Added file: http://bugs.python.org/file17288/zlib-8672.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 01:00:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 23:00:44 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273532444.45.0.692699517548.issue8672@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests -Library (Lib)
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 01:32:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 May 2010 23:32:11 +0000
Subject: [issue8682] _ssl.c uses PyWeakref_GetObject but doesn't incref result
In-Reply-To: <1273534331.53.0.523751841318.issue8682@psf.upfronthosting.co.za>
Message-ID: <1273534331.53.0.523751841318.issue8682@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

PyWeakref_GetObject() returns a borrowed reference, which can therefore become invalid at any time (especially when the GIL gets released). This provides a way to crash the interpreter deliberately.
The returned reference should be incref'ed immediately before any other action is taken.

----------
assignee: pitrou
components: Extension Modules
messages: 105481
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: _ssl.c uses PyWeakref_GetObject but doesn't incref result
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8682>
_______________________________________

From report at bugs.python.org  Tue May 11 02:51:42 2010
From: report at bugs.python.org (srid)
Date: Tue, 11 May 2010 00:51:42 +0000
Subject: [issue8683] HPUX Segmentation Fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>


New submission from srid <sridharr at activestate.com>:

Platform: HP-UX B.11.22 U ia64
Python: 2.7 trunk

GDB output when running built `python` binary:

Program received signal SIGSEGV, Segmentation fault (si_code: 1).
0x40000000002a2510:1 in gc_list_merge (from=0x148, to=0x148)
    at Modules/gcmodule.c:240
240         if (!gc_list_is_empty(from)) {

and the stack trace:

(gdb) bt
#0  0x40000000002a2510:1 in gc_list_merge (from=0x148, to=0x148)
    at Modules/gcmodule.c:240
#1  0x40000000002a4720:0 in collect (generation=0) at Modules/gcmodule.c:975
#2  0x40000000002a6620:0 in _PyObject_GC_Malloc (basicsize=65598)
    at Modules/gcmodule.c:996
#3  0x400000000018e540:0 in PyType_GenericAlloc (type=0x1003e, nitems=65598)
    at Objects/typeobject.c:743
#4  0x40000000003107d0:0 in PyDescr_NewWrapper (type=0x0, base=0x1003e, 
    wrapped=0x1003e) at Objects/descrobject.c:641
#5  0x40000000001a4570:0 in add_operators (type=0x0)
    at Objects/typeobject.c:6388
#6  0x4000000000193670:0 in PyType_Ready (type=0x1003e)
    at Objects/typeobject.c:4003
#7  0x40000000001485b0:0 in _Py_ReadyTypes () at Objects/object.c:2092
#8  0x4000000000270980:0 in Py_InitializeEx (install_sigs=0)
    at Python/pythonrun.c:176
#9  0x40000000002720e0:0 in Py_Initialize () at Python/pythonrun.c:370
#10 0x400000000009da70:0 in Py_Main (argc=0, argv=0x0) at Modules/main.c:507
#11 0x400000000009c770:0 in main (argc=0, argv=0x0) at ./Modules/python.c:23

----------
components: Interpreter Core
messages: 105482
nosy: srid
priority: normal
severity: normal
status: open
title: HPUX Segmentation Fault in Modules/gcmodule.c -- if (!gc_list_is_empty(from)) {
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Tue May 11 02:56:23 2010
From: report at bugs.python.org (srid)
Date: Tue, 11 May 2010 00:56:23 +0000
Subject: [issue8683] HPUX Segmentation fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273539383.85.0.404515187838.issue8683@psf.upfronthosting.co.za>


Changes by srid <sridharr at activestate.com>:


----------
nosy: +pitrou
title: HPUX Segmentation Fault in Modules/gcmodule.c -- if (!gc_list_is_empty(from)) { -> HPUX Segmentation fault in Modules/gcmodule.c -- if (!gc_list_is_empty(from)) {

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Tue May 11 06:27:52 2010
From: report at bugs.python.org (Josiah Carlson)
Date: Tue, 11 May 2010 04:27:52 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>


New submission from Josiah Carlson <josiahcarlson at users.sourceforge.net>:

This patch is against Python trunk, but it could be easily targeted for Python 3.2 .  It is meant to extract the scheduler updates from issue1641 without mucking with asyncore.  It's reach is reduced and simplified, which should make maintenance a bit easier.

----------
assignee: giampaolo.rodola
components: Library (Lib)
files: sched.patch
keywords: needs review, patch, patch
messages: 105483
nosy: giampaolo.rodola, josiahcarlson
priority: low
severity: normal
status: open
title: improvements to sched.py
type: feature request
Added file: http://bugs.python.org/file17289/sched.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Tue May 11 06:32:10 2010
From: report at bugs.python.org (Josiah Carlson)
Date: Tue, 11 May 2010 04:32:10 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1273552330.89.0.540493679518.issue1641@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

Some prodding from Giampaolo got me to pull out and simplify the sched.py changes here: issue8684 .

That should be sufficient to add scheduling behavior into async socket servers or otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Tue May 11 09:11:33 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Tue, 11 May 2010 07:11:33 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273561893.3.0.665518185827.issue8678@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

According to PEP-0004, affected module was deprecated in 2.5 and is no longer part of 2.6 and later.  Hence 2.5 only, not sure if that version is still actively supported upstream.

----------
nosy: +thoger
versions:  -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Tue May 11 09:44:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 07:44:06 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273563846.92.0.692734987649.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

I've tested a variant of the previous patch.
On my laptop, it gives good performance for simple cases, and the penalty for real-quoting case is very low.

I've tested a short-circuit for the unquote() function too.

----------
nosy: +flox
Added file: http://bugs.python.org/file17290/issue1285086_fast_quote.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 09:54:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 07:54:05 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273564445.78.0.830510470847.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17290/issue1285086_fast_quote.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 09:54:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 07:54:28 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273564468.81.0.269006497235.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file17291/issue1285086_fast_quote.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 10:37:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 11 May 2010 08:37:56 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273567076.11.0.112414825635.issue1285086@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Lets also see how this fares in py3k (where quote function takes an encoding ) and possibly push it in.
If there is any hesitation we can consult python-dev or wsgi groups where frameworks developers might review and voice concerns, if they have any.

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 10:55:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 08:55:20 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273568120.03.0.574243239289.issue8510@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Roumen:  good catch!  Indeed, nested functions aren't legal in standard C, and the test for -fno-strict-aliasing now fails on my OS X 10.6.3 machine, where it used to pass:

  checking whether gcc accepts -fno-strict-aliasing... no

config.log contains:

  configure:5400: checking whether gcc accepts -fno-strict-aliasing
  configure:5418: gcc -fno-strict-aliasing -c -g -O2  conftest.c >&5
  conftest.c: In function 'main':
  conftest.c:27: error: nested functions are disabled, use -fnested-functions to re-enable
  configure:5418: $? = 1
  configure: failed program was:
  ...

Fixed these cases above and removed the extra '#include "confdefs.h"' lines (which seem harmless, but unnecessary) in r81077 (trunk).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Tue May 11 11:04:19 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 11 May 2010 09:04:19 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>


New submission from Andrew Bennetts <spiv at users.sourceforge.net>:

set.difference(s), when s is also a set, basically does::

    res = set()
    for elem in self:
        if elem not in other:
            res.add(elem)

This is wasteful when len(self) is much greater than len(other):

$ python -m timeit -s "s = set(range(100000)); sd = s.difference; empty = set()" "sd(empty)"
100 loops, best of 3: 12.8 msec per loop
$ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)"
1000000 loops, best of 3: 1.18 usec per loop

Here's a patch that compares the lengths of self and other before that loop, and if len(self) is greater, swaps them.  The new timeit results are:

$ python -m timeit -s "s = set(range(100000)); sd = s.difference; empty = set()" "sd(empty)"
1000000 loops, best of 3: 0.289 usec per loop
$ python -m timeit -s "s = set(range(10)); sd = s.difference; empty = set()" "sd(empty)"
1000000 loops, best of 3: 0.294 usec per loop

----------
components: Interpreter Core
files: set-difference-speedup.diff
keywords: patch
messages: 105489
nosy: spiv
priority: normal
severity: normal
status: open
title: set(range(100000)).difference(set()) is slow
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file17292/set-difference-speedup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue May 11 11:24:08 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 11 May 2010 09:24:08 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273569848.69.0.43346229824.issue8685@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Oops, obvious bug in this patch. set('abc') - set('bcd') != set('bcd') - set('abc').  I'll see if I can make a more sensible improvement.

See also <http://bugs.python.org/issue8425>.  Thanks dickinsm on #python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue May 11 11:24:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 09:24:33 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273569873.08.0.757060778959.issue8510@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged to py3k, and fixed up an additional nested 'int main()', in r81078.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Tue May 11 11:27:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 09:27:06 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273570026.17.0.0331567681798.issue8685@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue May 11 11:31:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 09:31:02 +0000
Subject: [issue8425] a -= b should be fast if a is a small set and b is a
	large set
In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za>
Message-ID: <1273570262.89.0.825060630229.issue8425@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 8685.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8425>
_______________________________________

From report at bugs.python.org  Tue May 11 11:53:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 09:53:36 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273571616.38.0.242552705458.issue8510@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, it looks as though the nested functions were introduced in r76030;  nothing to do with Matthias's autoconf 2.65 update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Tue May 11 12:14:00 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 11 May 2010 10:14:00 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273572840.63.0.285566688411.issue8685@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Ok, this time test_set* passes :)

Currently if you have large set and small set the code will do len(large) lookups in the small set.  When large is >> than small, it is cheaper to copy large and do len(small) lookups in large.  On my laptop a size difference of 4 times is a clear winner for copy+difference_update over the status quo, even for sets of millions of entries.  For more similarly sized sets (even only factor of 2 size difference) the cost of allocating a large set that is likely to be shrunk significantly is greater than the benefit.  So my patch only switches behaviour for len(x)/4 > len(y).

This patch is complementary to the patch in issue8425, I think.

----------
Added file: http://bugs.python.org/file17293/set-difference-speedup-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue May 11 12:23:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 10:23:20 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273573400.24.0.82170315933.issue8510@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just double checked that r80969 didn't introduce any other non-whitespace changes: apart from the now-fixed OS X 10.5 SDK issue), the only other non-whitespace change was:

@@ -7018,7 +7023,7 @@
 int
 main ()
 {
-long double x; x = (long double)0.;
+long double x; x = (long double)0;
   ;
   return 0;
 }

which looks harmless to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Tue May 11 12:34:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 10:34:14 +0000
Subject: [issue8510] update to autoconf2.65
In-Reply-To: <1272036380.69.0.623365048341.issue8510@psf.upfronthosting.co.za>
Message-ID: <1273574054.49.0.365119039014.issue8510@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing.  Roumen, please open a new issue for any other configure issues that aren't related to this autoconf update.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8510>
_______________________________________

From report at bugs.python.org  Tue May 11 13:12:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 11:12:04 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273576324.41.0.548705222794.issue8684@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This must be retargeted to 3.2. Also, the patch lacks some tests.
It seems PEP 8 compliance could be better: function names shouldn't be CamelCased.
Is LocalSynchronize() an implementation detail rather than a public API? If so, I think it would be better if it started with an underscore.

----------
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Tue May 11 13:13:56 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 11 May 2010 11:13:56 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ratio
> This isn?t defined beyond that it is an upper bound on ratio(), and is faster to compute.

"beyond" is a bit confusing because it also means "over" and this
sentence refers upper bound.

I think "This isn't defined in detail more than..." is easier.

----------
assignee: docs at python
components: Documentation
messages: 105498
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: "This isn't defined beyond that" phrase is not friendly to non-native English speakers.
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Tue May 11 13:15:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 11:15:19 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273576519.64.0.629729323488.issue8684@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, the patch lacks docs for new public APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Tue May 11 13:40:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 11:40:10 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273578010.36.0.0410260691726.issue3704@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There is a reason, and that is that it may break existing code in the field relying on the current behavior.  This is (unfortunately) true regardless of whether the function is public or private, though the fact that it is ostensibly private is likely to reduce the amount of breakage.  The fix needs to be evaluated to try to guess whether breakage is likely, and if it is, it would not be a candidate for backport to 2.6 or 3.1.

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Tue May 11 13:52:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 11:52:05 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273578725.95.0.745755853508.issue3704@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I didn't read your comment carefully enough before I replied.  I think you are saying that the bug fix is confined to the routine in question and doesn't change even its API, in which case the nature of the function doesn't come in to it at all.  The fix still needs to be evaluated for backport, though, since it is a behavior change.  (For example, in another issue Senthil fixed parsing of unknown schemes to be RFC compliant, but we may need to back that fix out of 2.6 since it changes behavior and will most likely break currently working 2.6 code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Tue May 11 14:21:54 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 May 2010 12:21:54 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273580514.45.0.674365756691.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What are the enhancements introduced by this patch?
A faster cancel() implementation?
If so some simple benchmarks showing the speed improvement of cancel() and eventually also other methods like enterabs() and run() would be nice to have.

I've noticed there are no existing tests for the sched module.
This is very bad. I think the first thing to do is adding tests, make sure they pass with the current implementation, then apply the patch and make sure they keep passing.

Obviously it is also crucial that this patch is fully backward compatible with the current implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Tue May 11 14:28:06 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 May 2010 12:28:06 +0000
Subject: [issue8687] sched.py module doesn't have a test suite
In-Reply-To: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>
Message-ID: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

sched.py module is currently lacking a test suite.
Possibly this should be resolved before fixing issue 8684.

----------
components: Tests
messages: 105503
nosy: giampaolo.rodola, josiah.carlson, josiahcarlson, pitrou
priority: normal
severity: normal
status: open
title: sched.py module doesn't have a test suite
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8687>
_______________________________________

From report at bugs.python.org  Tue May 11 14:31:54 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 May 2010 12:31:54 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273581114.26.0.897201193643.issue8684@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Created issue 8687 to address the test suite problem.

----------
superseder:  -> sched.py module doesn't have a test suite

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Tue May 11 14:32:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 11 May 2010 12:32:48 +0000
Subject: [issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The sdist command in distutils calculates the MANIFEST file from a template (by default MANIFEST.in). 

The code in sdist assumes that the contents of MANIFEST only depends on MANIFEST.in and setup.py, which can cause files to be missed when building an sdist.

In particular: given a MANIFEST.in file that includes all documentation in a 'Doc' subdirectory, using"recursive-include Doc *.txt" in the template, the MANIFEST won't get regenerated when a new file is added to the documentation subdirectory and hence that new file is not included in sdist distributions.

----------
assignee: tarek
components: Distutils
messages: 105505
nosy: ronaldoussoren, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: distutils sdist is too laze w.r.t. recalculating MANIFEST
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/issue8688>
_______________________________________

From report at bugs.python.org  Tue May 11 14:41:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 12:41:55 +0000
Subject: [issue8675] audioop module needs an int -> Py_ssize_t upgrade
In-Reply-To: <1273516685.47.0.439722259241.issue8675@psf.upfronthosting.co.za>
Message-ID: <1273581715.69.0.399654106173.issue8675@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file17294/audioop_Py_ssize_t.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8675>
_______________________________________

From report at bugs.python.org  Tue May 11 15:05:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 13:05:18 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273583118.96.0.705974847714.issue8686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unfortunately that wouldn't be correct English, as far as I know.

How about "This isn't defined other than that..."  I think that reads a bit more clearly than "beyond that" even to a native speaker, even though beyond is valid in this context.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Tue May 11 15:05:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 13:05:32 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273583132.58.0.0600273549319.issue8686@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.1 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Tue May 11 15:07:24 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 May 2010 13:07:24 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1273583244.03.0.935975933623.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agree with Michael - one test that covers multiple settings can easily be done by collecting results within the test itself and then checking at the end that no failures were detected (e.g. I've done this myself with a test that needed to be run against multiple input files - the test knew the expected results and maintained lists of filenames where the result was incorrect. At the end of the test, if any of those lists contained entries, the test was failed, with the error message giving details of which files had failed and why).

What parameterised tests could add which is truly unique is for each of those files to be counted and tracked as a separate test. Sometimes the single-test-with-internal-failure-recording will still make more sense, but tracking the tests individually will typically give a better indication of software health (e.g. in my example above, the test ran against a few dozen files, but the only way to tell if it was one specific file that was failing or all of them was to go look at the error message).

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Tue May 11 15:07:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 13:07:31 +0000
Subject: [issue8684] improvements to sched.py
In-Reply-To: <1273552070.58.0.496415961493.issue8684@psf.upfronthosting.co.za>
Message-ID: <1273583251.57.0.802251228358.issue8684@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +sched.py module doesn't have a test suite
superseder: sched.py module doesn't have a test suite -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8684>
_______________________________________

From report at bugs.python.org  Tue May 11 15:11:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 13:11:41 +0000
Subject: [issue8674] audioop: incorrect integer overflow checks
In-Reply-To: <1273499009.24.0.283270137147.issue8674@psf.upfronthosting.co.za>
Message-ID: <1273583501.45.0.48968862447.issue8674@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed one more bogus overflow check in r81079 through r81082.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8674>
_______________________________________

From report at bugs.python.org  Tue May 11 15:29:40 2010
From: report at bugs.python.org (Sebastien Binet)
Date: Tue, 11 May 2010 13:29:40 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273584580.73.0.173270813567.issue1381@psf.upfronthosting.co.za>


Sebastien Binet <binet at cern.ch> added the comment:

hi there,

it seems there is still a problem, at least with asinh(-2j)

see:

$ python
Python 2.6.5 (r265:79063, Apr  1 2010, 05:28:39) 
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import numpy as np
>>> np.__version__
'1.4.0'
>>> import cmath
>>> cmath.asinh(-2j)
 (1.3169578969248166-1.5707963267948966j)

>>> np.arcsinh(-2j)
(-1.3169578969248164-1.5707963267948966j)

same behaviour for python3.1:
$ python3
Python 3.1.2 (r312:79147, Apr  1 2010, 09:12:21) 
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import cmath
>>> cmath.asinh(-2j)
(1.3169578969248166-1.5707963267948966j)

cheers,
sebastien.

----------
nosy: +bins
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 15:35:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 13:35:14 +0000
Subject: [issue8675] audioop module needs an int -> Py_ssize_t upgrade
In-Reply-To: <1273516685.47.0.439722259241.issue8675@psf.upfronthosting.co.za>
Message-ID: <1273584914.23.0.0179547078522.issue8675@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The audioop module was made PY_SSIZE_T_CLEAN in r81083.

----------
components: +Extension Modules
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8675>
_______________________________________

From report at bugs.python.org  Tue May 11 15:39:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 13:39:45 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273585185.98.0.0492901863881.issue1381@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Python's result looks fine to me, as does numpy's: they're both giving a valid inverse hyperbolic sine:

>>> from cmath import sinh
>>> sinh(1.3169578969248166-1.5707963267948966j)  
(1.0605752387249067e-16-1.9999999999999998j)
>>> sinh(-1.3169578969248164-1.5707963267948966j)
(-1.0605752387249064e-16-1.9999999999999993j)

Perhaps numpy is using different branch cuts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 15:44:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 13:44:34 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273585474.6.0.0487336692341.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

New patch, using str.translate instead of regexp.
It is faster for normal cases (85% less time than stdlib quote), and the penalty for the real-quoting case is less than 5%.

It should apply to 3.x with some adaptation.

----------
Added file: http://bugs.python.org/file17295/issue1285086_using_translate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 15:57:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 May 2010 13:57:13 +0000
Subject: [issue8687] sched.py module doesn't have a test suite
In-Reply-To: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>
Message-ID: <1273586233.11.0.377012090772.issue8687@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file17296/test_sched.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8687>
_______________________________________

From report at bugs.python.org  Tue May 11 16:00:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 14:00:16 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273586416.86.0.100876062303.issue1381@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A bit more explanation:  Python takes account of the sign of zero when deciding which side of the branch cut a value lies, which is the proper thing to do when you have signed zeros available (according to the likes of Kahan, anyway);  I suspect that numpy isn't doing that, but is treating all values that lie directly on a branch in the same way.

In this case there's a branch cut from -1j down to -1j*inf.  Values just to the right of that branch cut (i.e., with positive real part) should have a result with positive real part;  values just to the left of it should have negative real part:

Some results (using complex() to create the values, since other ways of creating complex numbers are prone to changing the sign of a zero):

>>> asinh(complex(0.0, -2.0))
(1.3169578969248166-1.5707963267948966j)
>>> asinh(complex(1e-10, -2.0))
(1.3169578969248166-1.5707963267371616j)
>>> asinh(complex(-0.0, -2.0))
(-1.3169578969248166-1.5707963267948966j)
>>> asinh(complex(-1e-10, -2.0))
(-1.3169578969248166-1.5707963267371616j)

So the cmath module is working as intended here.  numpy may or may not be working as intended:  I don't know how much they care about branch cut continuity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 16:02:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 14:02:36 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273586556.89.0.909390687407.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The speed test script did not work on 2.5 (because timeit.Timer does not accept a callable).
Fixed version, which benchmarks the str.translate(...) version.

Change the '_new_quote_setup' assignment to test other variants.

----------
Added file: http://bugs.python.org/file17297/urllib_quote_speed_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 16:05:17 2010
From: report at bugs.python.org (Sebastien Binet)
Date: Tue, 11 May 2010 14:05:17 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273586717.3.0.549109788708.issue1381@psf.upfronthosting.co.za>


Sebastien Binet <binet at cern.ch> added the comment:

hi Mark,

that may very well be so, but I'd naively standardize on C/Fortran behaviour (but that's probably my physicist bias)

on my platform, the following piece of C-code:

$ cat test_cmath.c
#include <complex.h>
#include <stdio.h>

int main(int argc, char** argv)
{
  complex c = casinh(-2*I);
  printf("asinh(-2j) = %g + %gi\n", creal(c), cimag(c));
  return 0;
}
/* EOF */

gives:
$ ./a.out 
asinh(-2j) = -1.31696 + -1.5708i

cheers,
sebastien.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 16:08:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 14:08:25 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273586905.2.0.983214499111.issue1381@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> that may very well be so, but I'd naively standardize on C/Fortran > behaviour (but that's probably my physicist bias)

Yep, that's exactly what Python does. :)  (Also follows the LISP standard).

Note that in your program, you're feeding complex(-0.0, -2.0) to asinh,
not complex(0.0, 2.0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 16:10:16 2010
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Tue, 11 May 2010 14:10:16 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1273583244.03.0.935975933623.issue7897@psf.upfronthosting.co.za>
Message-ID: <20100511141011.GE20127@onerussian.com>


Yaroslav Halchenko <yarikoptic at gmail.com> added the comment:

Hi Nick,

Am I reading your right, Are you suggesting to implement this
manual looping/collecting/reporting separately in every unittest
which needs that?

On Tue, 11 May 2010, Nick Coghlan wrote:
> Nick Coghlan <ncoghlan at gmail.com> added the comment:

> I agree with Michael - one test that covers multiple settings can easily be done by collecting results within the test itself and then checking at the end that no failures were detected (e.g. I've done this myself with a test that needed to be run against multiple input files - the test knew the expected results and maintained lists of filenames where the result was incorrect. At the end of the test, if any of those lists contained entries, the test was failed, with the error message giving details of which files had failed and why).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Tue May 11 16:11:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 14:11:49 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273587109.75.0.917400742495.issue1381@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Note that in your program, you're feeding complex(-0.0, -2.0) to asinh,
> not complex(0.0, 2.0).

Bah;  that should be complex(0.0, -2.0) in the second line, of course.

Anyway, try passing conj(2*I) to asinh in your C program and see what happens.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 17:01:06 2010
From: report at bugs.python.org (Sebastien Binet)
Date: Tue, 11 May 2010 15:01:06 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1273590066.51.0.556564240262.issue1381@psf.upfronthosting.co.za>


Sebastien Binet <binet at cern.ch> added the comment:

> Note that in your program, you're feeding complex(-0.0, -2.0) to asinh,
> not complex(0.0, -2.0).

ah!
(ducking)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
_______________________________________

From report at bugs.python.org  Tue May 11 17:42:11 2010
From: report at bugs.python.org (Christophe Simonis)
Date: Tue, 11 May 2010 15:42:11 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1273592531.92.0.94532240801.issue7978@psf.upfronthosting.co.za>


Changes by Christophe Simonis <simonis.christophe at gmail.com>:


----------
nosy: +Christophe Simonis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Tue May 11 17:43:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 15:43:43 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273592623.8.0.139567231701.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17297/urllib_quote_speed_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 17:44:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 15:44:11 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273592651.26.0.818883841109.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

actually, there's a simpler implementation, using s.rstrip(always_safe + safe).

It is as fast as the previous one.

----------
Added file: http://bugs.python.org/file17298/issue1285086_using_rstrip.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 17:44:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 May 2010 15:44:19 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273592659.9.0.790785511535.issue8256@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Tue May 11 17:48:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 11 May 2010 15:48:24 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1273592904.34.0.878156028237.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file17299/urllib_quote_speed_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Tue May 11 17:52:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 May 2010 15:52:26 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273593146.96.0.666499484698.issue8685@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue May 11 18:11:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 May 2010 16:11:04 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273594264.54.0.74576440732.issue8685@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have two problems with this proposal:

1. In constrained memory environments, creating a temporary internal copy of a large set may cause the difference operation to fail that would otherwise succeed.

2. The break-even point between extra lookups and a copy is likely to be different on different systems or even on the same system under different loads.

Programs that suffer from poor large_set.difference(small_set) performance can be rewritten as large_set_copy = large_set.copy(); large_set_copy.difference_updste(small_set) or even simply as large_set.difference_updste(small_set) if program logic allows it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue May 11 18:27:02 2010
From: report at bugs.python.org (Simon Jagoe)
Date: Tue, 11 May 2010 16:27:02 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>


New submission from Simon Jagoe <azriphale at gmail.com>:

I have been using sqlalchemy and sqlamp in a project for a while with Python 2.5.x and Python 2.6.4. With a recent upgrade to Python 2.6.5 (on Ubuntu Lucid Lynx), a particular operation began to fail when using sqlite.

I have tracked this to using the sqlite3 module and multiple parameter substitution. See below for a simple test case.

Set up the database:

 >>> import sqlite3
 >>> conn = sqlite3.connect('test.sqlite3')
 >>> c = conn.cursor()
 >>> c.execute('create table test (col integer)')
 >>> c.execute('insert into test values (1)')
 >>> conn.commit()

Actual result:

 >>> c.execute('SELECT coalesce(max(test.col), ?) + ? AS col FROM test', (0, 1))
 >>> c.fetchone()
 (None,)

Expected result:

 >>> c.execute('SELECT coalesce(max(test.col), ?) + ? AS col FROM test', (0, 1))
 >>> c.fetchone()
 (2,)

The expected result can be simulated like this:

 >>> c.execute('SELECT coalesce(max(test.col), 0) + 1 AS col FROM test')
 >>> c.fetchone()
 (2,)

----------
messages: 105525
nosy: azriphale
priority: normal
severity: normal
status: open
title: sqlite3 parameter substitution breaks with multiple parameters
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Tue May 11 18:55:35 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 11 May 2010 16:55:35 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1273596935.73.0.967941041182.issue1641@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Let the user leverage the existing scheduler API.  Cut out 
> scheduled_task and call_later, which just wraps the scheduler API.  
> The user can simply call scheduled_tasks.enter() or 
> scheduled_tasks.cancel().  It's one less API for them to learn and 
> one less for us to maintain.

I think a wrapper around sched.py is necessary.
Now that I wrote tests for it I realized its API is pretty rusty and old.


Adding a call:

scheduler = sched.scheduler(time.time, time.sleep)
scheduler.enter(10, 1, function, (arg,))

...vs:

asyncore.call_later(10, function, arg)


Cancelling a call:

scheduler = sched.scheduler(time.time, time.sleep)
event = scheduler.enter(10, 1, function, (arg,))
scheduler.cancel(event)

...vs:

event = asyncore.call_later(10, function, arg)
event.cancel()


Moreover, reset() and delay() methods are not implemented in sched.
By using call_later you can do:

event = asyncore.call_later(10, function, arg)
event.reset()
event.delay(10)

By using sched.py you'll have to recreate a new event from scratch (scheduler.cancel(event) -> calculate the new timeout, scheduler.enter(newtime, 1, function, (arg,)).

Other problems which comes to mind are: you can't easily know whether a call has already been cancelled, you can't manually fire it before the timeout has expired and I'm not even sure whether it's possible to pass kwargs to enter(), which is crucial (with call_later you can do it like this: asyncore.call_later(10, function, x, y, z='foo')).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Tue May 11 19:08:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 17:08:56 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1273596935.73.0.967941041182.issue1641@psf.upfronthosting.co.za>
Message-ID: <1273597428.3315.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Adding a call:
> 
> scheduler = sched.scheduler(time.time, time.sleep)
> scheduler.enter(10, 1, function, (arg,))
> 
> ...vs:
> 
> asyncore.call_later(10, function, arg)

I don't really see the difference. How hard it is to build a scheduler
object at startup and store it somewhere in your globals or on one of
your objects?

The main improvement I could see would be to make the arguments to
sched.scheduler() optional, and default to time.time and time.sleep.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Tue May 11 19:39:15 2010
From: report at bugs.python.org (srid)
Date: Tue, 11 May 2010 17:39:15 +0000
Subject: [issue8683] HPUX Segmentation fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273599555.29.0.746781783321.issue8683@psf.upfronthosting.co.za>


srid <sridharr at activestate.com> added the comment:

Still debugging it. In gcmodule.c:collect(..) the value of the variable `generation` is 80 - shouldn't it be less than NUM_GENERATIONS (3)?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Tue May 11 19:55:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 17:55:44 +0000
Subject: [issue8683] HPUX Segmentation fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273599555.29.0.746781783321.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273600691.3315.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Still debugging it. In gcmodule.c:collect(..) the value of the
> variable `generation` is 80 - shouldn't it be less than
> NUM_GENERATIONS (3)?

Certainly. Have you tried using different optimization options? Which
compiler are you using?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Tue May 11 19:56:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 11 May 2010 17:56:27 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1273596935.73.0.967941041182.issue1641@psf.upfronthosting.co.za>
Message-ID: <AANLkTilOLf0_nVMxX6r2e3Mm-rSa7eEV0fIzBhJSHOay@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Tue, May 11, 2010 at 11:55 AM, Giampaolo Rodola'
<report at bugs.python.org> wrote:
> Moreover, reset() and delay() methods are not implemented in sched.
>
> Other problems which comes to mind are: you can't easily know whether a call has already been cancelled, you can't manually fire it before the timeout has expired and I'm not even sure whether it's possible to pass kwargs to enter(), which is crucial (with call_later you can do it like this: asyncore.call_later(10, function, x, y, z='foo')).

These are nice features, but wouldn't it make more sense to add them to sched?

That would provide them to other users of sched, while keeping the
asyncore code simpler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Tue May 11 20:04:31 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 11 May 2010 18:04:31 +0000
Subject: [issue8683] HPUX Segmentation fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273601071.81.0.456232643808.issue8683@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I am using "cc: HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]" .. with the following options.

cc +DD64 -Ae -D_REENTRANT +Z -c  -g -DNDEBUG -O  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/gcmodule.o Modules/gcmodule.c

So that is +O2 level.

----

Interestingly the following patch fixes the bug, and shows that this is a optimization bug in HPUX compiler:

diff -r 549fd95a5eb9 Modules/gcmodule.c
--- a/Modules/gcmodule.c        Mon May 10 23:51:33 2010 +0200
+++ b/Modules/gcmodule.c        Tue May 11 11:02:52 2010 -0700
@@ -984,7 +984,8 @@
     /* Find the oldest generation (highest numbered) where the count
      * exceeds the threshold.  Objects in the that generation and
      * generations younger than it will be collected. */
-    for (i = NUM_GENERATIONS-1; i >= 0; i--) {
+    i = NUM_GENERATIONS-1;
+    while (i>=0){
         if (generations[i].count > generations[i].threshold) {
             /* Avoid quadratic performance degradation in number
                of tracked objects. See comments at the beginning
@@ -996,6 +997,7 @@
             n = collect(i);
             break;
         }
+       i--;
     }
     return n;
 }

----

I will try to use a different optimization level now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Tue May 11 20:21:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 May 2010 18:21:53 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273602113.91.0.998888045361.issue8678@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Because it's a crasher it could still be patched if someone chose to do the work.

----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Tue May 11 20:39:44 2010
From: report at bugs.python.org (Jason Baker)
Date: Tue, 11 May 2010 18:39:44 +0000
Subject: [issue8690] multiprocessing.dummy.Queue does not expose same
	interface as multiprocessing.Queue
In-Reply-To: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>
Message-ID: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

The multiprocessing.dummy.Queue class is merely an import of Queue.Queue.  There are a few methods that this does not provide however:  close, join_thread, and cancel_join_thread.

I don't know what the best way to handle this is, but it should be pretty trivial to add methods that do nothing or at least throw a NotImplementedError.

----------
components: Library (Lib)
messages: 105533
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: multiprocessing.dummy.Queue does not expose same interface as multiprocessing.Queue
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8690>
_______________________________________

From report at bugs.python.org  Tue May 11 20:43:43 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 11 May 2010 18:43:43 +0000
Subject: [issue8683] HPUX Segmentation fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273603423.82.0.209696077632.issue8683@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Using OPT="-O1" fixes this issue. Please feel free to close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Tue May 11 21:54:29 2010
From: report at bugs.python.org (angri)
Date: Tue, 11 May 2010 19:54:29 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273607669.96.0.042326083604.issue8689@psf.upfronthosting.co.za>


Changes by angri <general at angri.ru>:


----------
nosy: +angri

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Tue May 11 22:05:24 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 11 May 2010 20:05:24 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273608324.43.0.134515395591.issue3704@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

What specific breakage do you expect resulting from my patch being backported?

There is no behaviour change here, except to the minimal extent that all bug fixes involve behaviour change.  This seems a clear-cut backport candidate.

It's not a surprise to me that changing module urlparse to be compliant with RFC 3986 breaks code -- I suggested adding a new module instead for that reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Tue May 11 22:21:19 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:21:19 +0000
Subject: [issue8691] Doc: left alignment is not the default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

As reported on python-list by Alan G Isaac,
Lib Ref 6.1.3.1. Format Specification Mini-Language, for instance
http://docs.python.org/dev/py3k/library/string.html#formatstrings

wrongly says in the alignment section

"'<' 	Forces the field to be left-aligned within the available space (This is the default.)"

This latter, of course, is not true for number fields.

"(This is the default.)" could be replaced by "(the string default)."
(in any case, the '.' should be outside the () unless one is added after 'space' before '(') and "(the number default)" added to the next line. Or instead the issue of defaults could be addressed in the text below the table.

I am assuming that this issue affects 2.6/7.

----------
assignee: docs at python
components: Documentation
messages: 105536
nosy: docs at python, tjreedy
priority: normal
severity: normal
status: open
title: Doc: left alignment is not the default for numbers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8691>
_______________________________________

From report at bugs.python.org  Tue May 11 22:23:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 11 May 2010 20:23:01 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

(Making an educated guess about who to add to the Nosy list)

Attached is a patch to improve math.factorial by using a divide-and-conquer algorithm.  The old algorithm performs n-1 multiplications, mostly on numbers with a very large number of digits.

The algorithm in this patch:
- implicitly factors out all powers of two and applies a left-shift at the end.
- performs roughly half as many multiplications (around n/2 + 2*lg n)
- groups the multiplications so most multiplications are on small numbers
- uses a lookup table for n <= 12

There are faster factorial algorithms available, but they're significantly more complicated and rely on a fast prime factorization function.  This one is around 125 lines of code in C (with comments).  I have a pure-Python version that's around 25 lines of code, if anyone is interested.

Here are some timing results for different values of n:

n : old algorithm : new algorithm
1       0.14 us      0.10 us
10      0.63 us      0.12 us
13      0.81 us      0.76 us
100    12.6  us      4.92 us
1k    576    us    118    us
10k    53.6  ms      8.16 ms
100k   12.1  s     443    ms
1M      27   min    23    s
10M    forget it    20    min

I tested that both algorithms return the same answer for all values of n up to 10,000.

----------
assignee: stutzbach
components: Extension Modules
files: factorial.patch
keywords: needs review, patch, patch
messages: 105537
nosy: mark.dickinson, rhettinger, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Use divide-and-conquer for faster factorials
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17300/factorial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Tue May 11 22:26:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:26:54 +0000
Subject: [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1273609614.14.0.678930038218.issue4653@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Tue May 11 22:32:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:32:15 +0000
Subject: [issue965065] document docs.python.org in PEP-101
Message-ID: <1273609935.87.0.214137199563.issue965065@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PEP 101 now says
      ___ If this is a final release, also unpack the HTML docs to
          /data/ftp.python.org/pub/docs.python.org/release/X.Y[.Z].

___ If this is a major release: Tell the DE to adapt redirects for
          docs.python.org/X.Y in the Apache config for docs.python.org, update
          the script Doc/tools/dailybuild.py to point to the right
          stable/development branches, and to install it and make the initial
          checkout.

Does the above cover the intent of this issue?
(IE, should it be closed?)

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue965065>
_______________________________________

From report at bugs.python.org  Tue May 11 22:35:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:35:52 +0000
Subject: [issue2716] Reimplement audioop because of copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1273610152.05.0.139832677874.issue2716@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2716>
_______________________________________

From report at bugs.python.org  Tue May 11 22:38:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:38:20 +0000
Subject: [issue1397] mysteriously failing test_bsddb3 threading test in other
	threads
In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za>
Message-ID: <1273610300.44.0.490659608874.issue1397@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397>
_______________________________________

From report at bugs.python.org  Tue May 11 22:39:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:39:10 +0000
Subject: [issue3006] subprocess.Popen causes socket to remain open after close
In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za>
Message-ID: <1273610350.49.0.402637535848.issue3006@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3006>
_______________________________________

From report at bugs.python.org  Tue May 11 22:39:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:39:48 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1273610388.38.0.161986321494.issue3710@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Tue May 11 22:40:19 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:40:19 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1273610419.51.0.439767620557.issue1745035@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue May 11 22:41:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:41:41 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1273610501.86.0.586736223088.issue1615@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Tue May 11 22:42:23 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:42:23 +0000
Subject: [issue1868] threading.local doesn't free attrs when assigning thread
	exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1273610543.98.0.826767174505.issue1868@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
_______________________________________

From report at bugs.python.org  Tue May 11 22:45:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:45:13 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1273610713.51.0.963359744591.issue3657@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'works for me' contradicts 'open', so I unset that

----------
nosy: +tjreedy
resolution: works for me -> 
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Tue May 11 22:45:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:45:37 +0000
Subject: [issue5180] 3.1 cannot unpickle 2.7-created pickle
In-Reply-To: <1234045735.61.0.752787259691.issue5180@psf.upfronthosting.co.za>
Message-ID: <1273610737.19.0.727805931787.issue5180@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5180>
_______________________________________

From report at bugs.python.org  Tue May 11 22:46:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:46:04 +0000
Subject: [issue886488] WinPython 2.3.3 crashes using popen2 to spawn lots of
	child
Message-ID: <1273610764.75.0.241989364935.issue886488@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue886488>
_______________________________________

From report at bugs.python.org  Tue May 11 22:46:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:46:45 +0000
Subject: [issue2437] Distutils runtime_library_dirs broken on Windows
In-Reply-To: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za>
Message-ID: <1273610805.9.0.76990840234.issue2437@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 2.3, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2437>
_______________________________________

From report at bugs.python.org  Tue May 11 22:47:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 May 2010 20:47:00 +0000
Subject: [issue8575] Update/reorganize _winreg documentation
In-Reply-To: <1272600924.34.0.491501715071.issue8575@psf.upfronthosting.co.za>
Message-ID: <1273610820.17.0.914992498922.issue8575@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r81088-r81091.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8575>
_______________________________________

From report at bugs.python.org  Tue May 11 22:48:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:48:03 +0000
Subject: [issue5464] msgfmt.py does not work with plural form
In-Reply-To: <1236635230.35.0.0644981096799.issue5464@psf.upfronthosting.co.za>
Message-ID: <1273610883.55.0.404031299897.issue5464@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5464>
_______________________________________

From report at bugs.python.org  Tue May 11 22:48:41 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 May 2010 20:48:41 +0000
Subject: [issue1397] mysteriously failing test_bsddb3 threading test in other
	threads
In-Reply-To: <1194352164.91.0.707733802252.issue1397@psf.upfronthosting.co.za>
Message-ID: <1273610921.02.0.784383333292.issue1397@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

bsddb3 isn't in py3k.

----------
priority: high -> normal
versions:  -Python 2.5, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397>
_______________________________________

From report at bugs.python.org  Tue May 11 22:48:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:48:53 +0000
Subject: [issue3699] test_bigaddrspace broken
In-Reply-To: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
Message-ID: <1273610933.41.0.879442280137.issue3699@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3699>
_______________________________________

From report at bugs.python.org  Tue May 11 22:49:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:49:46 +0000
Subject: [issue1451466] reading very large files
Message-ID: <1273610986.14.0.25951466167.issue1451466@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this still an issue for 2.7?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1451466>
_______________________________________

From report at bugs.python.org  Tue May 11 22:50:50 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 May 2010 20:50:50 +0000
Subject: [issue8681] Make the zlib module emit more detailed error messages
In-Reply-To: <1273531059.62.0.905439523154.issue8681@psf.upfronthosting.co.za>
Message-ID: <AANLkTinQUT16JA86z4qJ-X5MfZhbwZZJsIFRF1Jm64o9@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

zliberrors.patch looks good to me.

On Mon, May 10, 2010 at 3:37 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> New submission from Antoine Pitrou <pitrou at free.fr>:
>
> This is a patch to use our own error descriptions when the zlib doesn't provide anything in particular. It would have made issue8672 easier to diagnose for the reporter (and for us).
>
> ----------
> components: Extension Modules
> files: zliberrors.patch
> keywords: patch
> messages: 105476
> nosy: gregory.p.smith, pitrou
> priority: normal
> severity: normal
> stage: patch review
> status: open
> title: Make the zlib module emit more detailed error messages
> type: behavior
> versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
> Added file: http://bugs.python.org/file17287/zliberrors.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8681>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8681>
_______________________________________

From report at bugs.python.org  Tue May 11 22:50:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:50:53 +0000
Subject: [issue1599254] mailbox: other programs' messages can vanish without
	trace
Message-ID: <1273611053.73.0.891094094248.issue1599254@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599254>
_______________________________________

From report at bugs.python.org  Tue May 11 22:51:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:51:39 +0000
Subject: [issue1646068] Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)
Message-ID: <1273611099.69.0.386604821755.issue1646068@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646068>
_______________________________________

From report at bugs.python.org  Tue May 11 22:52:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:52:04 +0000
Subject: [issue1669539] Change (fix!) os.path.isabs() semantics on Win32
Message-ID: <1273611124.77.0.37149013184.issue1669539@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669539>
_______________________________________

From report at bugs.python.org  Tue May 11 22:52:40 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:52:40 +0000
Subject: [issue4608] urllib.request.urlopen does not return an iterable object
In-Reply-To: <1228824822.91.0.748607079368.issue4608@psf.upfronthosting.co.za>
Message-ID: <1273611160.2.0.334975561246.issue4608@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4608>
_______________________________________

From report at bugs.python.org  Tue May 11 22:53:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:53:06 +0000
Subject: [issue5945] PyMapping_Check returns 1 for lists
In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za>
Message-ID: <1273611186.0.0.646788654451.issue5945@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5945>
_______________________________________

From report at bugs.python.org  Tue May 11 22:53:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:53:34 +0000
Subject: [issue1598083] Top-level exception handler writes to stdout unsafely
Message-ID: <1273611214.86.0.916442086678.issue1598083@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1598083>
_______________________________________

From report at bugs.python.org  Tue May 11 22:54:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:54:13 +0000
Subject: [issue4188] Lib/threading.py causes infinite recursion when running
	as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1273611253.29.0.933661684663.issue4188@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4188>
_______________________________________

From report at bugs.python.org  Tue May 11 22:55:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:55:31 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1273611331.17.0.327129269049.issue1621@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue May 11 22:55:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:55:56 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1273611356.42.0.884689070808.issue1621@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Tue May 11 22:56:40 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:56:40 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1273611400.23.0.896640461664.issue2122@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Tue May 11 22:57:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:57:34 +0000
Subject: [issue5219] IDLE/Tkinter: edit win stops updating when tooltip is
	active
In-Reply-To: <1234382300.54.0.847679485731.issue5219@psf.upfronthosting.co.za>
Message-ID: <1273611454.79.0.22177832117.issue5219@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5219>
_______________________________________

From report at bugs.python.org  Tue May 11 23:00:24 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 May 2010 21:00:24 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273611624.89.0.139621891093.issue8672@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Tue May 11 23:01:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 21:01:13 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1273611673.63.0.433571836962.issue2620@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Neal committed changes for 2.4,2.5, so I removed those.
3.0 is dead. Is this an issue for 3.1,3.2 or should it be closed?

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Tue May 11 23:01:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 21:01:41 +0000
Subject: [issue7152] urllib2.build_opener() skips ProxyHandler
In-Reply-To: <1255720004.18.0.991850721386.issue7152@psf.upfronthosting.co.za>
Message-ID: <1273611701.34.0.972945165611.issue7152@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7152>
_______________________________________

From report at bugs.python.org  Tue May 11 23:05:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 May 2010 21:05:16 +0000
Subject: [issue8575] Update/reorganize _winreg documentation
In-Reply-To: <1272600924.34.0.491501715071.issue8575@psf.upfronthosting.co.za>
Message-ID: <1273611916.33.0.882282123554.issue8575@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I should also note that the 2.6 and 3.1 commits also exposed the *ReflectionKey documentation. That documentation was added as part of a feature for 2.7/3.2, but those documentation pieces should have been backported on their own but were not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8575>
_______________________________________

From report at bugs.python.org  Tue May 11 23:14:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 21:14:08 +0000
Subject: [issue779285] Carbon Event ReceiveNextEvent
Message-ID: <1273612448.5.0.169247245002.issue779285@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have the strong impression that Carbon is no longer used (or is being phased out) in modern Mac ports of Python. Reopen is this is wrong and there is a problem in 2.6,7 or 3.1,2.

----------
nosy: +tjreedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue779285>
_______________________________________

From report at bugs.python.org  Tue May 11 23:18:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 May 2010 21:18:02 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273612682.8.0.24352779014.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've noticed that your patch changes 

>>> math.factorial(2.**63)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

to

>>> math.factorial(2.**63)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: factorial() not defined for negative values


While the error message is wrong in both cases, I think OverflowError is a better exception in this case and there should not be a difference between math.factorial(2.**63) and math.factorial(2**63) behavior.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Tue May 11 23:18:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 21:18:10 +0000
Subject: [issue3704] cookielib doesn't handle URLs with / in parameters
In-Reply-To: <1219856501.23.0.0473308500082.issue3704@psf.upfronthosting.co.za>
Message-ID: <1273612690.79.0.936060539501.issue3704@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't expect anything; I had written that it looked OK to me but apparently I accidentally deleted that text before posting.  But I'm not someone who has ever programmed using cookielib so I wouldn't expect my opinion to count for too much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3704>
_______________________________________

From report at bugs.python.org  Tue May 11 23:32:40 2010
From: report at bugs.python.org (Tim Hatch)
Date: Tue, 11 May 2010 21:32:40 +0000
Subject: [issue8016] Support for cp858
In-Reply-To: <1267057078.57.0.378294218982.issue8016@psf.upfronthosting.co.za>
Message-ID: <1273613560.5.0.0866546604742.issue8016@psf.upfronthosting.co.za>


Tim Hatch <tim at timhatch.com> added the comment:

Uploading corrected diff -- the old one missed a couple of instances of DOTLESS I -> EURO.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file17301/cp858.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8016>
_______________________________________

From report at bugs.python.org  Tue May 11 23:39:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 11 May 2010 21:39:43 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273612682.8.0.24352779014.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTildaxHelrqBaXAgUcaIDa969WjaQXE8ys39VK5C@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Tue, May 11, 2010 at 4:18 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> While the error message is wrong in both cases, I think OverflowError is a better exception in this case and there should not be a difference between math.factorial(2.**63) and math.factorial(2**63) behavior.

Good catch!? I will fix that tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Tue May 11 23:58:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 21:58:40 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273615120.59.0.0443199082885.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, I'm interested in seeing the pure Python version.  It could go into test_math, and would be a useful form of documentation.

Are there sufficient tests already in test_math.py to exercise the code thoroughly, or are more needed?

I'll try to find time to do a thorough code review in the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 00:33:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 May 2010 22:33:31 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273617211.59.0.766982968625.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I also started to wonder if a tighter upper limit for an acceptable argument can be found.

In discussion of issue2138 I saw the following exchange:

"""
> Should there be some upper limit on the argument math.factorial would
take?

I'd say not.  Any such limit would be artificial, and an arbitrary
choice.  Just let the natural time and space requirements be the
limiting factor.
""" - msg62541 - Mark Dickinson -

Still, the original and proposed implementations bail out if n is larger than system LONG_MAX.  This is not a limitation because because the result for LONG_MAX! would exceed the number of digits that python long integer can hold.

It seems to me that the value of n for which number of digits will exceed sys.maxsize can be estimated fairly accurately using Stirling formula.  Only two values are relevant in practice - one for sys.maxsize = 2**63-1 and the other for sys.maxsize = 2**31-1.  These values can be hardcoded and factorial can quickly report the case when n! will exceed maxsize digits instead of hanging until memory is exhausted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 00:35:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 May 2010 22:35:10 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1273617310.51.0.760713662381.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, I'm saying I don't see summarising the parameterised tests separately from the overall test run as a particularly important feature, since you can test multiple parameters in a single test manually now.

The important part is for the framework to be able to generate multiple tests from a single test function with a selection of arguments.  Doing a separate run with just those tests will give you any information that a summary would give you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed May 12 00:37:12 2010
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Tue, 11 May 2010 22:37:12 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273617432.53.0.535985091904.issue8256@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Amaury, could you elaborate a little more on this? I am pretty new to all this and I would happily write the patch, if only you could give me some clue on how I should approach this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Wed May 12 00:44:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 22:44:32 +0000
Subject: [issue8683] HPUX Segmentation fault in Modules/gcmodule.c -- if
	(!gc_list_is_empty(from)) {
In-Reply-To: <1273539102.07.0.573681131536.issue8683@psf.upfronthosting.co.za>
Message-ID: <1273617872.84.0.271032484727.issue8683@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I'm closing. Thank you for testing Python, anyway!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8683>
_______________________________________

From report at bugs.python.org  Wed May 12 01:20:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 May 2010 23:20:54 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273617211.59.0.766982968625.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTinOsDIIBV-iBZn6b8JFkX8vtkmFIDn4OjJaqmEE@mail.gmail.com>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On Tue, May 11, 2010 at 11:33 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> It seems to me that the value of n for which number of digits will exceed sys.maxsize can be estimated fairly accurately using Stirling formula. ?Only two values are relevant in practice - one for sys.maxsize = 2**63-1 and the other for sys.maxsize = 2**31-1. ?These values can be hardcoded and factorial can quickly report the case when n! will exceed maxsize digits instead of hanging until memory is exhausted.

Sure, bailing out for ridiculously large arguments sounds fine to me.
On a 64-bit machine, there can be at most 2**61 4-byte digits, each
digit giving containing 30 bits of the long.  So the maximum
representable long (under the implausible assumption that someone
could actually find 2**63 bytes of storage) would be around
2**(30*2**61).  The following quick search gives me a value of around
1.18e18 for the first n such that n! exceeds this value:

from math import log, lgamma

def bisect(f, a, b):
    c = (a + b)/2.0
    while a != c and b != c:
        a, b = (a, c) if f(c) else (c, b)
        c = (a + b)/2.0
    return c

BOUND = 2**62*15*log(2)
print(bisect(lambda x: lgamma(x) > BOUND, 2.0, 1e30))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 01:39:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 23:39:20 +0000
Subject: [issue8672] Error decompressing valid zlib data
In-Reply-To: <1273445046.81.0.821535662262.issue8672@psf.upfronthosting.co.za>
Message-ID: <1273621160.47.0.484862319665.issue8672@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch was committed in r81094 (2.7), r81095 (2.6), r81096 (3.2) and r81097 (3.1). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8672>
_______________________________________

From report at bugs.python.org  Wed May 12 01:42:28 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 11 May 2010 23:42:28 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273617211.59.0.766982968625.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTilraSE7gFoSVOsuN7LPFhWavoEMMBjil-IqB_gP@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Tue, May 11, 2010 at 5:33 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> It seems to me that the value of n for which number of digits will exceed sys.maxsize can be estimated fairly accurately using Stirling formula. ?Only two values are relevant in practice - one for sys.maxsize = 2**63-1 and the other for sys.maxsize = 2**31-1. ?These values can be hardcoded and factorial can quickly report the case when n! will exceed maxsize digits instead of hanging until memory is exhausted.

Isn't that adding an extra check in every case to speed up a
you-can't-seriously-expect-that-to-work corner case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 01:51:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 May 2010 23:51:09 +0000
Subject: [issue8681] Make the zlib module emit more detailed error messages
In-Reply-To: <1273531059.62.0.905439523154.issue8681@psf.upfronthosting.co.za>
Message-ID: <1273621869.44.0.42854327191.issue8681@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r81098 (2.7), r81099 (2.6), r81100 (3.2), r81101 (3.1). Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8681>
_______________________________________

From report at bugs.python.org  Wed May 12 02:03:44 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 12 May 2010 00:03:44 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1273622624.95.0.0165657361153.issue8679@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Wed May 12 02:04:16 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 12 May 2010 00:04:16 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1273622656.53.0.976046879349.issue8680@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Wed May 12 02:05:12 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 12 May 2010 00:05:12 +0000
Subject: [issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1273622712.44.0.216867349682.issue8688@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8688>
_______________________________________

From report at bugs.python.org  Wed May 12 02:14:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 00:14:19 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTilraSE7gFoSVOsuN7LPFhWavoEMMBjil-IqB_gP@mail.gmail.com>
Message-ID: <AANLkTin7wxsEQzhr6smLX8YKYtBy26v5K6I1bDiHNnJl@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 11, 2010 at 7:42 PM, Daniel Stutzbach
<report at bugs.python.org> wrote:
..
> Isn't that adding an extra check in every case to speed up a
> you-can't-seriously-expect-that-to-work corner case?
>

The check is cheap - just a machine integer comparison, so I would not
even take that cost into account.   In my view math.factorial() is
primarily of interest in educational settings where it is quite likely
that someone would be curious enough to pass sys.maxsize to it.

The main value in setting a theoretically justified limit is that
overflow exception can carry a meaningful message, e.g. "factorial
result would have too many digits", rather than an unhelpful "Python
int too large to convert to C long".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 02:38:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 00:38:41 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTilraSE7gFoSVOsuN7LPFhWavoEMMBjil-IqB_gP@mail.gmail.com>
Message-ID: <AANLkTil2JQ6qpoPMlBHo13d9m294iJr4_Ov5m_8fGfSr@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 11, 2010 at 7:42 PM, Daniel Stutzbach
<report at bugs.python.org> wrote:
..
> Isn't that adding an extra check in every case ...

Speaking of micro-optimizations, did you consider a better than naive
algorithm for "Count the number of set bits in n" in your patch?
HAKMEM 169 comes to mind and being a divide and conquer too, it seems
like a good fit.   Certainly an overkill if used just for
math.factorial(), but this is probably a useful function to have
around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 03:00:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 12 May 2010 01:00:43 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTin7wxsEQzhr6smLX8YKYtBy26v5K6I1bDiHNnJl@mail.gmail.com>
Message-ID: <AANLkTikJz2l2CPHh2TXIABXIJBcHQeROUfcRYU3kykQL@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Tue, May 11, 2010 at 7:15 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> The main value in setting a theoretically justified limit is that
> overflow exception can carry a meaningful message, e.g. "factorial
> result would have too many digits", rather than an unhelpful "Python
> int too large to convert to C long".

I'm pretty sure this is an orthogonal issue to speeding up
math.factorial.  If you want to improve the error and/or impose a
tighter maximum limit on n, would you mind opening it as a separate
issue?

I like extra checks and I like speed, but I can't think about adding
extra checks and a speed patch at the same time. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 03:07:56 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 12 May 2010 01:07:56 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTil2JQ6qpoPMlBHo13d9m294iJr4_Ov5m_8fGfSr@mail.gmail.com>
Message-ID: <AANLkTimglGfLBajFp3Kzx5eRInl3z7FjdLbibThQdVc6@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Tue, May 11, 2010 at 7:38 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> Speaking of micro-optimizations, did you consider a better than naive
> algorithm for "Count the number of set bits in n" in your patch?
> HAKMEM 169 comes to mind and being a divide and conquer too, it seems
> like a good fit. ? Certainly an overkill if used just for
> math.factorial(), but this is probably a useful function to have
> around.

I considered it, but decided to stick with code readability and
portability.  Counting the number of set bits is only done once per
factorial, so it's not on the critical path.

FWIW, the following page has a pretty extensive summary of performance
comparisons of different solutions to the "count the set bits"
problem:
http://www.dalkescientific.com/writings/diary/archive/2008/07/03/hakmem_and_other_popcounts.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 04:19:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 02:19:44 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTimglGfLBajFp3Kzx5eRInl3z7FjdLbibThQdVc6@mail.gmail.com>
Message-ID: <AANLkTikg3ykV7gmbvWzBaeH0CFT0v5iXByehtDt3ywmo@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 11, 2010 at 9:07 PM, Daniel Stutzbach
<report at bugs.python.org> wrote:
>
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
> On Tue, May 11, 2010 at 7:38 PM, Alexander Belopolsky
> <report at bugs.python.org> wrote:
>> Speaking of micro-optimizations, did you consider a better than naive
>> algorithm for "Count the number of set bits in n" in your patch?
>> ..
> I considered it, but decided to stick with code readability and
> portability.

Speaking of readability, with a separate popcount() function, you can
simply write

nminusnumbits_ob = PyLong_FromLong(n - popcount(n))

and eliminate not only the loop, but also num_bits and tmp variables
from math_factorial()

The popcount function can be defined as a __builtin_popcount on GCC
and your loop otherwise.

> ?Counting the number of set bits is only done once per
> factorial, so it's not on the critical path.
>

I agree, performance consideration are completely irrelevant here.

Similarly, while unlikely to improve performance, I would prefer not
to use any bit-trick implementation of ilog2 (in a separate function,
of course) instead of calling floating point log2.  In my head, an
assignment of floating point result to an integer variable always
raises a red flag.

Another readability nit:  for me k % 2 == 0 is a more readable check
for even number than (k & 1) != 1.  Performance-wise the two choices
are the same, and either can be improved by combining k = (n + m) / 2
and k & 1 into one ldiv call.

I have not tried to do it, but my gut feeling is that
factorial_part_product() can benefit from passing semi-open rather
than closed interval.  (Also renaming n and m to start and stop in
this case will help understanding.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 05:25:19 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 03:25:19 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>


New submission from Muhammad Bashir Al-Noimi <mbnoimi at gmx.com>:

After installing python-3.1.2.msi I'm not able to run to python.exe at all because it gives me the following error message:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

PS
    * I'm using WinXp SP3 32Bit

----------
components: Windows
files: error.log
messages: 105566
nosy: mbnoimi
priority: normal
severity: normal
status: open
title: Py_Initialize: can't initialize sys standard streams
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file17302/error.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 05:27:52 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 03:27:52 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273634872.45.0.013752434252.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

I uninstalled python-2.6.3 before installing python-3.1.2.msi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 05:45:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 03:45:00 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTikg3ykV7gmbvWzBaeH0CFT0v5iXByehtDt3ywmo@mail.gmail.com>
Message-ID: <AANLkTilTpAqy59ez3UhAu4wLA9QAMLUgsOeBuU__CDli@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 11, 2010 at 10:19 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Similarly, while unlikely to improve performance, I would prefer not
> to use any bit-trick implementation of ilog2 (in a separate function,
> of course) instead of calling floating point log2. ?In my head, an
> assignment of floating point result to an integer variable always
> raises a red flag.
>

Searching for relevant past issues, I've come across a similar
sentiment from Mark:

"""
floor(log(n, 2)) is poor code.  This is not supposed to be a dramatic
statement, just a statement of fact.  Its correctness is dependent on
minute details of floating point.  It is poor code in exactly the same way
that "while x < 1.0: x += 0.1" is poor code---behaviour in boundary cases
is almost entirely unpredictable.
""" - msg78066 - Mark Dickinson -

I also noticed that the reference implementation does not require this
calculation because the loop is implemented recursively.  Did you find
recursive implementation to give worse performance?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 06:07:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 May 2010 04:07:41 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273637261.98.0.402477733125.issue8693@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of issue1616979.

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> cp720 encoding map

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 06:48:05 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 04:48:05 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273639685.25.0.647063928823.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

No No, this isn't duplicated issue because if I copied cp720.py to Python31\Lib\encodings

Python still crashed and gives me the following error

----
Fatal Python error: Py_Initialize: can't initialize sys standard streams
TypeError: 'NoneType' object is not callable

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 06:48:18 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 04:48:18 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273639698.17.0.0370138798547.issue8693@psf.upfronthosting.co.za>


Changes by Muhammad Bashir Al-Noimi <mbnoimi at gmx.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 06:58:01 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 04:58:01 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273640281.81.0.301545133783.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

This is the file I'm adding for removing warning message which is not the reason of crashing

----------
Added file: http://bugs.python.org/file17303/cp720.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 07:17:46 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 05:17:46 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273641466.67.0.69941145915.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

humm I re-read issue1616979

I'm confused is it really duplicate issue? if yes I couldn't find the way for fixing in issue1616979

PS
I'm newbie in Python and I faced this problem in first day I use Python so please forgive me if my discussion is stupid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 08:06:08 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 06:06:08 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273644368.17.0.399840512094.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

For fixing this issue I tried to following:

1) Installed python-2.6.3.msi
2) Downloaded cp720.py, genwincodec.py from http://svn.python.org/view?rev=74000&view=rev
3) Copied cp720.py it to Python31\Lib\encodings
4) Run Python31\python.exe I got the following error:
---
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "C:\Python31\lib\encodings\__init__.py", line 98, in search_function
    level=0)
  File "C:\Python31\lib\encodings\cp720.py", line 50
    u'\x00'     #  0x00 -> CONTROL CHARACTER
          ^
SyntaxError: invalid syntax

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
---
5) copied genwincodec.py to Python26
6) Run C:\Python26>python.exe genwincodec.py 720  1>C:\Python31\Lib\encodings\cp720.py I got the following error message:
---
Traceback (most recent call last):
  File "genwincodec.py", line 8, in <module>
    from gencodec import codegen
ImportError: No module named gencodec
---

What's wrong? that's really exhausted! I didn't face this problem with any programming language before (I'm C++/Qt developer)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 08:14:31 2010
From: report at bugs.python.org (Nathan Phillip Brink)
Date: Wed, 12 May 2010 06:14:31 +0000
Subject: [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>


New submission from Nathan Phillip Brink <ohnobinki at ohnopublishing.net>:

http://docs.python.org/py3k/faq/programming.html#what-does-unicodeerror-ascii-decoding-encoding-error-ordinal-not-in-range-128-mean

When I try to use unicode() from within python3, the call fails. I would actually expect that the FAQ should contain more information concerning the merging of the unicode and str classes. It would be nice if, when this FAQ entry is updated, there is a short discussion on making the code compatible with both python2 and python3, as it appears that's the only way python3 adaption will ever happen.

----------
assignee: docs at python
components: Documentation
messages: 105574
nosy: docs at python, ohnobinki
priority: normal
severity: normal
status: open
title: python3 FAQ mentions unicode()
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8694>
_______________________________________

From report at bugs.python.org  Wed May 12 08:29:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 May 2010 06:29:27 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273645767.26.0.461597295204.issue8693@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please trust me that this *is* a duplicate issue.

This bug tracker is not a place to get help; it is a place to report bugs. The bug you are reporting has been reported before. Other duplicate reports are #6995, #7496, #7600, #8120.

If you want help, contact python-list at python.org (aka news:comp.lang.python).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 08:49:46 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 06:49:46 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273646986.3.0.869112903049.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

Thanks and I'm very sorry for disturbance I'll try to get help through mailing list you've mentioned

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 10:08:34 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 12 May 2010 08:08:34 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1273651714.81.0.478197092407.issue1128@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

A slightly different patch is attached to issue7639, which generates short names more similar to Windows/NTFS:
 
http://bugs.python.org/file15898/msilib_make_short.diff

Here are some short names created with the msilib_make_short patch, which are identical to the short names created by the Windows NTFS file system:

foo.txt             ->  FOO.TXT
foo.2.txt           ->  FOO2~1.TXT
someLongName.txt    ->  SOMELO~1.TXT
someLongerName.txt  ->  SOMELO~2.TXT

For comparison, the msilib-2 patch generates these short names:

foo.txt             ->  FOO.TXT
foo.2.txt           ->  FOO.2.TXT    <- different from NTFS
someLongName.txt    ->  SOMELO~1.TXT
someLongerName.txt  ->  SOMELO~2.TXT

----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
_______________________________________

From report at bugs.python.org  Wed May 12 10:28:47 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 12 May 2010 08:28:47 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1273652927.71.0.309672425912.issue6470@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

This issue is also present in Python 2.7b2.

The svn trunk requires a slightly different patch (attached).

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file17304/Tkinter-import-UNCW-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6470>
_______________________________________

From report at bugs.python.org  Wed May 12 10:50:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 May 2010 08:50:07 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273654207.37.0.409752338492.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some quick comments:

(1) Agree about the extra bound checks:  let's treat those as a separate issue and just concentrate on performance here.

(2) log2 isn't portable:  it's not part of C89 (though it is in C99) and I don't think it exists on Windows.  Which is a shame, since it probably *does* reliably work well for boundary cases on most platforms.  I'm embarrassed to read that snippet that Alexander found, but it's true that an alternative like log(n)/log(2) has problems in boundary cases, thanks to the usual floating-point issues.  There's a bit-counting method in the int.bit_length() implementation (in Objects/longobject.c) that could possibly be re-used here.  Alternatively, if a simple for-loop to count bits doesn't have any noticeable impact on speed, then we could use that.

(3) Is the 'count set bits' code a bottleneck?  If not, then it looks fine to me as it is.  Doesn't it just get called once per factorial computation?

(4) I wonder whether the recursion in factorial_part_product slows things down;  it might be interesting to compare with an iterative version (but still one that clumps together small pieces rather than doing lots of small*big multiplies).  It seems possible that the cost of the recursive calls is insignificant compared to the cost of the various Py* calls, though.

(5) Was there a reason for using long rather than unsigned long for the computations?  Using unsigned long would give you an easily computable multiply_cutoff, and save the need for that extra static variable (it could be a macro instead).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From mbnoimi at gmx.com  Wed May 12 05:56:32 2010
From: mbnoimi at gmx.com (M. Bashir Al-Noimi)
Date: Wed, 12 May 2010 05:56:32 +0200
Subject: Py_Initialize: can't initialize sys standard streams
Message-ID: <4BEA26F0.4000400@gmx.com>

Hi All,

After installing python-3.1.2.msi I'm not able to run to python.exe at 
all because it gives me the following error message:

> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> LookupError: unknown encoding: cp720
>
> This application has requested the Runtime to terminate it in an 
> unusual way.
> Please contact the application's support team for more information.


*How I can fix this issue?*

*PS*

    * I'm using WinXp SP3 32Bit
    * I uninstalled python-2.6.3 before installing python-3.1.2.msi


-- 
Best Regards
Muhammad Bashir Al-Noimi
My Blog: http://mbnoimi.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100512/2bf798bb/attachment.html>

From report at bugs.python.org  Wed May 12 12:51:26 2010
From: report at bugs.python.org (Senthil)
Date: Wed, 12 May 2010 10:51:26 +0000
Subject: [issue8695] Issue while installing Python 2.6.5 in IBM AIX 6.1
In-Reply-To: <1273661486.25.0.2216975723.issue8695@psf.upfronthosting.co.za>
Message-ID: <1273661486.25.0.2216975723.issue8695@psf.upfronthosting.co.za>


New submission from Senthil <senthil_l at infosys.com>:

Hi,
I am trying to install Python 2.6.5 in IBM AIX(6.1) machine. The make seems to failing with the following error.

Fatal Python error: Interpreter not initialized (version mismatch?)
make: *** [sharedmods] IOT/Abort trap (core dumped)

----------
components: Build
files: logs.zip
messages: 105580
nosy: senthil_l
priority: normal
severity: normal
status: open
title: Issue while installing Python 2.6.5 in IBM AIX 6.1
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17305/logs.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8695>
_______________________________________

From report at bugs.python.org  Wed May 12 13:33:32 2010
From: report at bugs.python.org (Muhammad Bashir Al-Noimi)
Date: Wed, 12 May 2010 11:33:32 +0000
Subject: [issue8693] Py_Initialize: can't initialize sys standard streams
In-Reply-To: <1273634719.18.0.842243568226.issue8693@psf.upfronthosting.co.za>
Message-ID: <1273664012.1.0.0914759030418.issue8693@psf.upfronthosting.co.za>


Muhammad Bashir Al-Noimi <mbnoimi at gmx.com> added the comment:

Lie Ryan gave me the solution,

copy http://svn.python.org/view/python/branches/py3k/Lib/encodings/cp720.py?view=markup to Python31\Lib\encodings

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8693>
_______________________________________

From report at bugs.python.org  Wed May 12 13:33:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 May 2010 11:33:41 +0000
Subject: [issue8695] Issue while installing Python 2.6.5 in IBM AIX 6.1
In-Reply-To: <1273661486.25.0.2216975723.issue8695@psf.upfronthosting.co.za>
Message-ID: <1273664021.17.0.658613790084.issue8695@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you propose a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8695>
_______________________________________

From report at bugs.python.org  Wed May 12 13:54:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 May 2010 11:54:48 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1273665288.98.0.670715144428.issue2620@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
_______________________________________

From report at bugs.python.org  Wed May 12 14:30:51 2010
From: report at bugs.python.org (christen)
Date: Wed, 12 May 2010 12:30:51 +0000
Subject: [issue1451466] reading very large files
In-Reply-To: <1273610986.14.0.25951466167.issue1451466@psf.upfronthosting.co.za>
Message-ID: <4BEA9DD3.9070607@unice.fr>


christen <Richard.Christen at unice.fr> added the comment:

I have no idea because
- I am using 2.5 (windows) or 2.6 (2.5 because of old stuff that I 
compiled compatible with 2.5 not 2.6)
- I am using open(file, 'U') that solved the problem under windows, and 
the pd does not exist in Linux
best
Richard

Terry J. Reedy a ?crit :
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Is this still an issue for 2.7?
>
> ----------
> nosy: +tjreedy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1451466>
> _______________________________________
>
>
>

----------
nosy: +Richard.Christen at unice.fr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1451466>
_______________________________________

From report at bugs.python.org  Wed May 12 14:55:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 12 May 2010 12:55:37 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1273668937.58.0.803232911747.issue6610@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +astrand, pitrou
stage: needs patch -> patch review
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________

From report at bugs.python.org  Wed May 12 15:13:46 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 13:13:46 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273670026.29.0.239010935767.issue8686@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

How about just dropping those words entirely, and writing "Return an approximate upper bound on ratio() very quickly.  This is not as accurate as ratio(), but is faster to compute."  (We'd make similar changes to real_quick_ratio()'s text.)

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Wed May 12 15:14:57 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Wed, 12 May 2010 13:14:57 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273670097.33.0.157851393088.issue8685@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Regarding memory, good question... but this patch turns out to be an improvement there too.

This optimisation only applies when len(x) > len(y) * 4.  So the minimum size of the result is a set with 3/4 of the elems of x (and possibly would be a full copy of x anyway).

So if you like this optimisation is simply taking advantage of the fact we're going to be copying almost all of these elements anyway.  We could make it less aggressive, but large sets are tuned to be between 1/2 and 1/3 empty internally anyway, so 1/4 overhead seems reasonable.

Also, because this code immediately makes the result set be about the right size, rather than growing it one element at a time, the memory consumption is actually *better*.  I'll attach a script that demonstrates this; for me it shows that large_set.difference(small_set) [where large_set has 4M elems, small_set has 100] peaks at 50MB memory consumption without my patch, but only 18MB with.  (after discounting the memory required for large_set itself, etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Wed May 12 15:15:39 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Wed, 12 May 2010 13:15:39 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273670139.64.0.584203756307.issue8685@psf.upfronthosting.co.za>


Changes by Andrew Bennetts <spiv at users.sourceforge.net>:


Added file: http://bugs.python.org/file17306/set-mem.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Wed May 12 15:19:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 May 2010 13:19:15 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273670355.48.0.179066082593.issue8685@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 1. In constrained memory environments, creating a temporary internal
> copy of a large set may cause the difference operation to fail that
> would otherwise succeed.

It's a space/time tradeoff. There's nothing wrong about that.
(do note that hash tables themselves take much more space than the "equivalent" list)

> 2. The break-even point between extra lookups and a copy is likely to
> be different on different systems or even on the same system under
> different loads.

So what? It's just a matter of choosing reasonable settings. There are other optimization heuristics in the interpreter.

The optimization here looks ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Wed May 12 15:24:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 May 2010 13:24:00 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1273670640.26.0.707514522836.issue6610@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________

From report at bugs.python.org  Wed May 12 16:27:13 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:27:13 +0000
Subject: [issue8697] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674433.55.0.29048689936.issue8697@psf.upfronthosting.co.za>
Message-ID: <1273674433.55.0.29048689936.issue8697@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached patch adds a first cut at documenting the PEP 391 dictConfig() feature.  I've taken the PEP 391 text and rearranged it to fit into the existing logging module docs.  I haven't gone through every paragraph and adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the PEP.

* The details of the dictionary schema are moved to be first instead of last.  I therefore rewrote the paragraph in the PEP beginning "Before describing the schema in detail..." to one that begins "Describing a logging configuration requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through the rest of the text adding Sphinx markup, and commit the result.

Thanks!

----------
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105588
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17307/pep391-docs.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8697>
_______________________________________

From report at bugs.python.org  Wed May 12 16:27:13 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:27:13 +0000
Subject: [issue8696] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674433.57.0.0627786943755.issue8696@psf.upfronthosting.co.za>
Message-ID: <1273674433.57.0.0627786943755.issue8696@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached patch adds a first cut at documenting the PEP 391 dictConfig() feature.  I've taken the PEP 391 text and rearranged it to fit into the existing logging module docs.  I haven't gone through every paragraph and adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the PEP.

* The details of the dictionary schema are moved to be first instead of last.  I therefore rewrote the paragraph in the PEP beginning "Before describing the schema in detail..." to one that begins "Describing a logging configuration requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through the rest of the text adding Sphinx markup, and commit the result.

Thanks!

----------
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105587
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17308/pep391-docs.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8696>
_______________________________________

From report at bugs.python.org  Wed May 12 16:27:19 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:27:19 +0000
Subject: [issue8698] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674437.89.0.924445396649.issue8698@psf.upfronthosting.co.za>
Message-ID: <1273674437.89.0.924445396649.issue8698@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached patch adds a first cut at documenting the PEP 391 dictConfig() feature.  I've taken the PEP 391 text and rearranged it to fit into the existing logging module docs.  I haven't gone through every paragraph and adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the PEP.

* The details of the dictionary schema are moved to be first instead of last.  I therefore rewrote the paragraph in the PEP beginning "Before describing the schema in detail..." to one that begins "Describing a logging configuration requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through the rest of the text adding Sphinx markup, and commit the result.

Thanks!

----------
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105589
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17309/pep391-docs.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8698>
_______________________________________

From report at bugs.python.org  Wed May 12 16:29:00 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:29:00 +0000
Subject: [issue8697] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674433.55.0.29048689936.issue8697@psf.upfronthosting.co.za>
Message-ID: <1273674540.84.0.587165609977.issue8697@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8697>
_______________________________________

From report at bugs.python.org  Wed May 12 16:29:18 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 14:29:18 +0000
Subject: [issue8698] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674437.89.0.924445396649.issue8698@psf.upfronthosting.co.za>
Message-ID: <1273674558.99.0.147982776479.issue8698@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8698>
_______________________________________

From report at bugs.python.org  Wed May 12 16:43:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 14:43:38 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273615120.59.0.0443199082885.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTik9yHKYF6OU6fNjpSr5IeJwlKlInM7OVGG5wBej@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 11, 2010 at 5:58 PM, Mark Dickinson <report at bugs.python.org> wrote:
> Yes, I'm interested in seeing the pure Python version.

Here is my translation of the reference implementation.

>??It could go into test_math, and would be a useful form of documentation.

Note that I copied the reference implementation recursive logic rather
than that in the proposed patch.  It may be better for documentation
this way.

If we end up using something like this in documentation, I would
rename nminusnumofbits() to something more readable.  Maybe "ntwos" or
"count_trailing_zeros" with an explanation why number of factors of 2
in factorial(n) is n - popcount(n).

----------
Added file: http://bugs.python.org/file17310/factorial.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
import functools
import operator

product = functools.partial(functools.reduce, operator.mul)

def naive_factorial(n):
    """Naive implementation of factorial: product([1, ..., n])

    >>> naive_factorial(4)
    24
    """
    return product(range(1, n+1), 1)

def factorial(n):
    """Implementation of Binary-Split Factorial algorithm

    See http://www.luschny.de/math/factorial/binarysplitfact.html

    >>> for n in range(20):
    ...     assert(factorial(n) == naive_factorial(n))
    """
    _, r = loop(n, 1, 1)
    return r << nminusnumofbits(n)

def loop(n, p, r):
    if n > 2:
        p, r = loop(n // 2, p, r)
        p *= partial_product(n // 2 + 1 + ((n // 2) & 1),  n - 1 + (n & 1))
        r *= p
    return p, r

def partial_product(n, m):
    if m <= n + 1:
        return n
    if m == n + 2:
        return n * m
    k = (n + m) // 2
    if k & 1 != 1:
        k -= 1
    return partial_product(n, k) * partial_product(k + 2, m)

def nminusnumofbits(n):
    nb = 0
    v = n
    while v:
        nb += v & 1
        v >>= 1
    return n - nb


if __name__ == '__main__':
    import doctest
    doctest.testmod()

From report at bugs.python.org  Wed May 12 17:00:50 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 12 May 2010 15:00:50 +0000
Subject: [issue8699] Equality and hashing for functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

On python-dev came up an idea [1] to support equality (== and !=) and hashing by functools.partial instances.  Van Lindberg provided an implementation written in Python [2].  I've made a very similar implementation in C (in Modules/_functoolsmodule.c).  The Python equivalent of my code is in Lib/test/test_functools.py as the PythonPartialCls class.  The hashing differs a little from Van Lindberg's implementation: I'm computing the "normal form" of the dict as the sorted list of its items (not as the sorted list of the keys followed by the items).  (It was easier to implement this way.)

I haven't made a lot of Python programming in C, so I'm not sure I made everything in the right way (especially the reference counting).  Anyway, I'm attaching my patch.  I'd appreciate every suggestion, and will try to correct my mistakes.
Thanks!

[1] http://mail.python.org/pipermail/python-dev/2010-May/099981.html
[2] http://mail.python.org/pipermail/python-dev/2010-May/099996.html

----------
components: Extension Modules
files: partial_eq_hash.diff
keywords: patch
messages: 105591
nosy: durban
priority: normal
severity: normal
status: open
title: Equality and hashing for functools.partial
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17311/partial_eq_hash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8699>
_______________________________________

From report at bugs.python.org  Wed May 12 17:13:47 2010
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 12 May 2010 15:13:47 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273677227.93.0.265106528918.issue8692@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 17:28:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 15:28:24 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTikg3ykV7gmbvWzBaeH0CFT0v5iXByehtDt3ywmo@mail.gmail.com>
Message-ID: <AANLkTim61n5Wp8ttjtKSPzUFzjVfaOgWzeWIGwhRRiTJ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 11, 2010 at 10:19 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Another readability nit: ?for me k % 2 == 0 is a more readable check
> for even number than (k & 1) != 1. ?Performance-wise the two choices
> are the same, and either can be improved by combining k = (n + m) / 2
> and k & 1 into one ldiv call.

Strike this comment.  For some reason I though GCC would optimize
division by 2 and inline ldiv, but apparently neither is true.

Still,

if ((k & 1) != 1)
          k = k - 1;

looks odd to me. Maybe k += (k & 1) - 1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 17:36:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 12 May 2010 15:36:37 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273678597.41.0.607321997508.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thank you both for the valuable feedback.  I'm working on a revised patch that incorporates your many suggestions.

I decided to use an iterative version for two reasons:
- the reference has a note at the bottom in a tiny font suggesting it
- I found it counter-intuitive to implement product() as a recursive function.  I had a much easier time matching the code up with the formula when it was implemented iteratively.

I agree that my use of log2() was an ugly hack. ;-)  I'll fix that.

Would it be worthwhile to create a pybits.h and .c that defines _Py_FindLastSetBit and _Py_CountSetBits? (with appropriate logic in the .h and configure.in to use system/compiler versions if available)

There are already two implementations of find-last-set-bit in Python: 
bits_in_digit() in Objects/longobject.c and hi0bits() in Python/dtoa.c.  It would be nice to consolidate them.

(hi0bits counts the leading 0 bits which is a trivial transformation of finding the highest set bit)

I don't know of anyplace else in Python that needs count-set-bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 18:01:04 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 12 May 2010 16:01:04 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTim61n5Wp8ttjtKSPzUFzjVfaOgWzeWIGwhRRiTJ@mail.gmail.com>
Message-ID: <AANLkTinC_5l5402K-kpj4hdTFsEM0in_4D-FyF-KDYWG@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Wed, May 12, 2010 at 10:31 AM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> if ((k & 1) != 1)
> ? ? ? ? ?k = k - 1;
>
> looks odd to me. Maybe k += (k & 1) - 1?

If we change the logic slightly to put the odd entry on the right
instead of the left, we can do:

        k = (n + m) / 2;
        k |= 1; /* Ensure that k is odd */
        left = factorial_part_product(n, k-2);
        if (left == NULL) goto done;
        right = factorial_part_product(k, m);
        if (right == NULL) goto done;

That will split 1*3*5*7*9*11 into (1*3*5) * (7*9*11), just like the
old code.  It will split 1*3*5*7*9 into (1*3) * (5*7*9) while the old
code did (1*3*5) * (7*9), which is fine.

It's easier to read and fewer operations. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 19:52:05 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 12 May 2010 17:52:05 +0000
Subject: [issue8696] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674433.57.0.0627786943755.issue8696@psf.upfronthosting.co.za>
Message-ID: <1273686725.51.0.374748822918.issue8696@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Andrew - the patch looks good - thanks! A few places were "will be" could be replaced with "has been" or some such to indicate that the implementation now exists.

Please go ahead with the other changes.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8696>
_______________________________________

From report at bugs.python.org  Wed May 12 19:59:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 May 2010 17:59:05 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273687145.76.0.970541386666.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Now that I've looked at the patch properly:

I'm +1 on including some version of this patch.  At the time that the original math.factorial went in (see issue 2138) we were hurrying a bit to get it in before the first 2.6 beta, so ended up with a simple implementation, with the understanding (I think) that it could be improved later.

It looks like you and Alexander are doing a great job of hammering out the fine detail;  I only have a few comments at this stage.  I predict that you're not going to like the first one ;-).  The others are just technical issues.

(1) In the interests of simplicity, please could we lose the 'long' optimization in factorial_part_product?  That is, get rid of the if (m == n+2) branch, and just let that case recurse normally---which means that we end up calling PyNumber_Multiply in some cases instead of doing a C long by C long multiplication.  Then we can get rid of multiply_cutoff entirely.  I'm +1 on the improved algorithm, and I realize that the optimization does have an effect (some unscientific tests showed me a 18% speed increase in typical cases) but for me this optimization goes past the simplicity/speed tradeoff.  There's always the option of adding something like this back in later, once the new algorithm's gone in.

(2) You're missing a Py_DECREF(part) in factorial_loop, so factorial(n) leaks references (for n > 12).

(3) The line "k = (n + m) / 2;" in factorial_part_product invokes undefined behaviour (from signed overflow) if n and m are large.  We're not going to get meaningful results in this case anyway, but UB should be avoided if at all possible.  Perhaps rewrite this as "k = n + (m - n) / 2;"?

(4) And please do restore the PyLong_FromDouble line in the main routine, rather than using a C double-to-long cast.  The direct conversion again leads to undefined behaviour for large doubles (cf. C99 6.3.1.4,p2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 20:03:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 May 2010 18:03:31 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273687411.15.0.152867658016.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> (cf. C99 6.3.1.4,p2).

Oops.  C99 6.3.1.4,p1.  That'll teach me not to cite chapter and verse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 20:29:39 2010
From: report at bugs.python.org (Balachander Ganesan)
Date: Wed, 12 May 2010 18:29:39 +0000
Subject: [issue8700] strip() is removing an extra character if the strip
	pattern contains "-"
In-Reply-To: <1273688979.04.0.976435378464.issue8700@psf.upfronthosting.co.za>
Message-ID: <1273688979.04.0.976435378464.issue8700@psf.upfronthosting.co.za>


New submission from Balachander Ganesan <gb.balachander at gmail.com>:

Version:
========
Python 2.4.3 (#1, Jan 14 2008, 18:31:21)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2

Description:
============
When the pattern used for strip contains "-" character then it removes one more characters next to it.

>>> a = 'image-abc-1.2.0-12_1234_123'
>>> b = a.strip('image-')
>>> print b
bc-1.2.0-12_1234_123


>From the above print statement we can see that instead of 'bc-1.2.0-12_1234_123', it prints only 'bc-1.2.0-12_1234_123'. 
The first character "a" next to "-" is missing.

----------
components: Library (Lib)
messages: 105598
nosy: Balachander.Ganesan
priority: normal
severity: normal
status: open
title: strip() is removing an extra character if the strip pattern contains "-"
type: behavior
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8700>
_______________________________________

From report at bugs.python.org  Wed May 12 20:31:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 May 2010 18:31:25 +0000
Subject: [issue8700] strip() is removing an extra character if the strip
	pattern contains "-"
In-Reply-To: <1273688979.04.0.976435378464.issue8700@psf.upfronthosting.co.za>
Message-ID: <1273689085.09.0.952553101601.issue8700@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The argument to strip is a set of characters to remove, not a substring.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8700>
_______________________________________

From report at bugs.python.org  Wed May 12 20:37:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 12 May 2010 18:37:50 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273687145.76.0.970541386666.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTimy5Bkz6ixw7ni0MscpdobRjdamBO1-09HyYbZu@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Wed, May 12, 2010 at 12:59 PM, Mark Dickinson <report at bugs.python.org> wrote:
> (4) And please do restore the PyLong_FromDouble line in the main routine, rather than using a C double-to-long cast. ?The direct conversion again leads to undefined behaviour for large doubles (cf. C99 6.3.1.4,p2).

I was planning to add a "if (dx > (double) LONG_MAX)" check.  Would
that be sufficient?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 20:57:15 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 18:57:15 +0000
Subject: [issue8696] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674433.57.0.0627786943755.issue8696@psf.upfronthosting.co.za>
Message-ID: <1273690635.35.0.200841723077.issue8696@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Thanks!  Committed to trunk in rev81125.

----------
assignee: vinay.sajip -> akuchling
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8696>
_______________________________________

From report at bugs.python.org  Wed May 12 21:08:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 May 2010 19:08:01 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273691281.25.0.139513169858.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>I was planning to add a "if (dx > (double) LONG_MAX)" check.  Would
> that be sufficient?

Hmm.  It's subtle.  On an LP64 machine, LONG_MAX will be 2**63-1, which isn't exactly representable as a double.  So (double) LONG_MAX would likely be 2.0**63 exactly (depending on rounding mode, but round-half-to-even is probably a safe assumption unless someone's deliberately messing around).  Then that check would fail for dx == 2.**63 exactly.

Turn it into '>=' rather than '>', and I *think* it's okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 21:15:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 12 May 2010 19:15:29 +0000
Subject: [issue8046] mmap.mmap as a context manager
In-Reply-To: <1267587593.82.0.663403244999.issue8046@psf.upfronthosting.co.za>
Message-ID: <1273691729.47.0.142441305015.issue8046@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8046>
_______________________________________

From report at bugs.python.org  Wed May 12 21:24:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 19:24:15 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273654207.37.0.409752338492.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTik2C5Ul-NiqZELPgOpDQhS0Vc-4NSUkrMjZa37g@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, May 12, 2010 at 4:50 AM, Mark Dickinson  wrote:
..
> (4) I wonder whether the recursion in factorial_part_product slows things down; ??it might be interesting to compare with an iterative version (but still one that clumps together small pieces rather than doing lots of small*big multiplies). ??It seems possible that the cost of the recursive calls is insignificant compared to the cost of the various Py* calls, though.

I am attaching a little study of three different part_product
implementations in python: the recursive one, straight product, and
not-recursive binary division:

$ ./python.exe -m timeit -s "import factorial3 as fm;
fm.partial_product = fm.partial_product; f = fm.factorial " "f(10000)"
10 loops, best of 3: 66.1 msec per loop
$ ./python.exe -m timeit -s "import factorial3 as fm;
fm.partial_product = fm.partial_product1; f = fm.factorial "
"f(10000)"
10 loops, best of 3: 67.6 msec per loop
$ ./python.exe -m timeit -s "import factorial3 as fm;
fm.partial_product = fm.partial_product2; f = fm.factorial "
"f(10000)"
10 loops, best of 3: 43.4 msec per loop

The last one seems to b a clear winner, but I am not certain where the
gain comes from - no recursion or first by last instead of ith by
(i+1)st multiplication.   Also python recursion overhead is probably
different from C.

----------
Added file: http://bugs.python.org/file17312/factorial3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
import functools
import operator

product = functools.partial(functools.reduce, operator.mul)

def naive_factorial(n):
    """Naive implementation of factorial: product([1, ..., n])

    >>> naive_factorial(4)
    24
    """
    return product(range(1, n+1), 1)

def factorial(n):
    """Implementation of Binary-Split Factorial algorithm

    See http://www.luschny.de/math/factorial/binarysplitfact.html

    >>> for n in range(20):
    ...     assert(factorial(n) == naive_factorial(n))
    >>> import math
    >>> assert(factorial(100) == math.factorial(100))
    """
    _, r = loop(n)
    return r << (n - count_bits(n))

def loop(n):
    p = r = 1
    for i in range(n.bit_length() - 2, -1, -1):
        m = n >> i
        if m > 2:
            p *= partial_product(((m >> 1) + 1) >> 1, (m - 1) >> 1)
            r *= p
    return p, r

def partial_product(j, i):
    if i == j:
        return j << 1 | 1
    if i == j + 1:
        return (j << 1 | 1) * (i << 1 | 1)
    l = i + j >> 1
    return partial_product(j, l) * partial_product(l + 1, i)

def partial_product1(j, i):
    return product((l << 1 | 1 for l in range(j, i + 1)), 1)

def partial_product2(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    n = i - j + 1
    p = 1
    while n:
        n >>= 1
        for k in range(n):
            a[k] *= a[n-k]
    return a[0]

def count_bits(n):
    count = 0
    while n:
        n &= n - 1
        count += 1
    return count

if __name__ == '__main__':
    import doctest
    doctest.testmod()

From report at bugs.python.org  Wed May 12 21:47:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 May 2010 19:47:44 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273693664.96.0.298446297195.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Interesting---thanks for the analysis!

Realistically though, I don't see an iterative version of factorial_part_product as an option for the C patch, without a significant increase in complexity.  Daniel's current patch is remarkably clean and simple, and I'd like to keep it that way.

I did think about various evil schemes for an iterative version, but didn't come up with anything I'd want to see in the Python codebase.  (The worst of these schemes involved using a union of long and PyObject * to try to increase the possibilities for doing simple C long multiplication, and using the fact that you can easily tell the difference between an odd long and a (4-byte aligned) PyObject * just by looking at the last bit.  But I'm fairly sure that comes under the 'evil' heading.  :) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Wed May 12 21:57:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 May 2010 19:57:36 +0000
Subject: [issue2138] Add a factorial function
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1273694256.96.0.795356169585.issue2138@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

maix:  good point.  Fixed in revisions r81126 through r81129.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
_______________________________________

From report at bugs.python.org  Wed May 12 22:11:06 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 12 May 2010 20:11:06 +0000
Subject: [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273695066.89.0.280637504257.issue8694@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8694>
_______________________________________

From report at bugs.python.org  Wed May 12 22:21:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 May 2010 20:21:16 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273695676.55.0.568331156592.issue8686@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it's important to note that this may err towards larger numbers (rather than being merely inaccurate).

I also find this "an upper bound on ratio()" difficult to understand. IIUC, it is the correct value being bounded, not the result of the function under discussion that is bounded (by the correct value).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Wed May 12 22:34:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 May 2010 20:34:33 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273693664.96.0.298446297195.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTim4hvDUg5ySjsPUvdaXoSJVygyQyno8COwHKg7z@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is one more datapoint.

$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product; f = fm.factorial " "f(10000)"
10 loops, best of 3: 66.1 msec per loop
[32794 refs]
$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product3; f = fm.factorial "
"f(10000)"
10 loops, best of 3: 63 msec per loop
[32794 refs]
$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product2; f = fm.factorial "
"f(10000)"
10 loops, best of 3: 43.3 msec per loop

partial_product3 multiplies adjacent numbers instead of first by last.
 I am not sure it reproduces the order of multiplication in the
recursive version exactly, but it does show that the order of
multiplication matters a lot.

I wonder if one could write an elegant recursive version that would
multiply first by last in partial_product.

----------
Added file: http://bugs.python.org/file17313/factorial4.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
import functools
import operator

product = functools.partial(functools.reduce, operator.mul)

def naive_factorial(n):
    """Naive implementation of factorial: product([1, ..., n])

    >>> naive_factorial(4)
    24
    """
    return product(range(1, n+1), 1)

def factorial(n):
    """Implementation of Binary-Split Factorial algorithm

    See http://www.luschny.de/math/factorial/binarysplitfact.html

    >>> for n in range(20):
    ...     assert(factorial(n) == naive_factorial(n))
    >>> import math
    >>> assert(factorial(100) == math.factorial(100))
    """
    _, r = loop(n)
    return r << (n - count_bits(n))

def loop(n):
    p = r = 1
    for i in range(n.bit_length() - 2, -1, -1):
        m = n >> i
        if m > 2:
            p *= partial_product(((m >> 1) + 1) >> 1, (m - 1) >> 1)
            r *= p
    return p, r

def partial_product(j, i):
    if i == j:
        return j << 1 | 1
    if i == j + 1:
        return (j << 1 | 1) * (i << 1 | 1)
    l = i + j >> 1
    return partial_product(j, l) * partial_product(l + 1, i)

def partial_product1(j, i):
    return product((l << 1 | 1 for l in range(j, i + 1)), 1)

def partial_product2(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    n = i - j + 1
    p = 1
    while n:
        n >>= 1
        for k in range(n):
            a[k] *= a[n-k]
    return a[0]

def partial_product3(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    while 1:
        n = len(a)
        if n == 1:
            return a[0]
        a = [a[k<<1] * a[k<<1|1] for k in range(n>>1)] + a[(n >> 1)<<1:]


def count_bits(n):
    count = 0
    while n:
        n &= n - 1
        count += 1
    return count

if __name__ == '__main__':
    #print(partial_product(10, 20))
    import doctest
    doctest.testmod()

From report at bugs.python.org  Wed May 12 22:42:25 2010
From: report at bugs.python.org (Tim Peters)
Date: Wed, 12 May 2010 20:42:25 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273696945.68.0.627673850359.issue8686@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I find this whole discussion to be hilarious ;-)

"Approximate upper bound" is gibberish - "upper bound" is a crisp concept that means what it says.  It's not necessarily true that an upper bound is inaccurate - it may be exactly right.  So "this is not as accurate as ratio()" overstates the case.

"quick_ratio() returns an upper bound on what ratio() returns" is the truth, and can't be improved by adding more words.   Appealing to a "correct" result would also be misleading (what ratio() returns is a more-or-less arbitrary computation whose only claim to "correctness" is that ratio() returns what it's documented to return).

If people find the gloss in the docs confusing, remove the gloss entirely, leaving just the correct:

"Return an upper bound on ratio() relatively quickly."

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Wed May 12 23:19:39 2010
From: report at bugs.python.org (Poor Yorick)
Date: Wed, 12 May 2010 21:19:39 +0000
Subject: [issue8701] tarfile: first character of member names doubled
In-Reply-To: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>
Message-ID: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>


New submission from Poor Yorick <pooryorick at users.sourceforge.net>:

In the following file, for python 2.6.4, tarfile.list doubles the first character of each member name:

http://watson.nci.nih.gov/cran_mirror/src/contrib/Archive/time/time_1.0.tar.gz

gnu tar handles the file correctly

----------
components: Library (Lib)
messages: 105609
nosy: pooryorick
priority: normal
severity: normal
status: open
title: tarfile: first character of member names doubled
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8701>
_______________________________________

From report at bugs.python.org  Wed May 12 23:26:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 12 May 2010 21:26:52 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTim4hvDUg5ySjsPUvdaXoSJVygyQyno8COwHKg7z@mail.gmail.com>
Message-ID: <AANLkTikzMH9XM3-KXliVg6lnD22x9k4wr2oOLNYnX2pQ@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Wed, May 12, 2010 at 3:34 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> I wonder if one could write an elegant recursive version that would
> multiply first by last in partial_product.

That could be done with a three-parameter partial_product, where the
third parameter designates how many numbers to multiply.  Something
like this:

part_product(9, 17, 5) -> 9*11*13*15*17
  part_product(9, 17, 2) -> 9*17
  part_product(11, 15, 3) -> 11*13*15

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 00:56:52 2010
From: report at bugs.python.org (Jason Spiro)
Date: Wed, 12 May 2010 22:56:52 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1273705012.05.0.217118317298.issue3621@psf.upfronthosting.co.za>


Jason Spiro <jasonspiro4 at gmail.com> added the comment:

> Can you provide a patch?

Unfortunately not.  I still don't think it's worth fixing this bug.  :)  I think you should document it in the bdist_wininst documentation then close this bug as "won't fix due to lack of volunteer resources".  That way the problem will be documented both here and in that documentation, but nobody need spend the time to fix such a minor bug.

Or at least you should lower this bug's priority to the lowest setting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Thu May 13 01:36:24 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 12 May 2010 23:36:24 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1273707384.48.0.457395824671.issue3605@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I have a fix at http://codereview.appspot.com/1184043, which makes PyErr_Occurred() return NULL when there is no thread.  I'll commit it tomorrow unless there are comments.

----------
assignee:  -> jyasskin
keywords: +needs review
nosy: +jyasskin
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu May 13 01:43:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 May 2010 23:43:15 +0000
Subject: [issue8016] Support for cp858
In-Reply-To: <1267057078.57.0.378294218982.issue8016@psf.upfronthosting.co.za>
Message-ID: <1273707795.22.0.106363759718.issue8016@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, lemburg
stage:  -> patch review
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8016>
_______________________________________

From report at bugs.python.org  Thu May 13 01:49:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 May 2010 23:49:05 +0000
Subject: [issue8687] sched.py module doesn't have a test suite
In-Reply-To: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>
Message-ID: <1273708145.46.0.273396753895.issue8687@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You know, one benefit of having user-settable sleep() and time() functions is that you can mock them easily, and therefore check that sched.py really schedules callables at the right intervals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8687>
_______________________________________

From report at bugs.python.org  Thu May 13 01:52:04 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 12 May 2010 23:52:04 +0000
Subject: [issue8687] sched.py module doesn't have a test suite
In-Reply-To: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>
Message-ID: <1273708324.33.0.45718358855.issue8687@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I agree. Are you recommending to take advantage of this and change the tests in some way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8687>
_______________________________________

From report at bugs.python.org  Thu May 13 01:58:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 May 2010 23:58:51 +0000
Subject: [issue8687] sched.py module doesn't have a test suite
In-Reply-To: <1273708324.33.0.45718358855.issue8687@psf.upfronthosting.co.za>
Message-ID: <1273708878.3267.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I agree. Are you recommending to take advantage of this and change the
> tests in some way?

Yes, it would allow you to check that if you have e.g. :
- A scheduled in 1 s
- B scheduled in 3 s

sched.py first sleeps for 1 s, then calls A, then sleeps for 2 s, then
calls B

Twisted has a full-blown utility class that they use in many tests,
allowing them to mock time.time():
http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.task.Clock.html
You probably don't need something as sophisticated, the idea of a class
with advance() and time() methods is probably enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8687>
_______________________________________

From report at bugs.python.org  Thu May 13 02:06:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 13 May 2010 00:06:30 +0000
Subject: [issue3621] it would be nice if installers made by bdist_wininst
	stored an EstimatedSize property in the Windows registry
In-Reply-To: <1219248850.4.0.277642755083.issue3621@psf.upfronthosting.co.za>
Message-ID: <1273709190.55.0.566682069286.issue3621@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3621>
_______________________________________

From report at bugs.python.org  Thu May 13 02:14:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 00:14:26 +0000
Subject: [issue8256] TypeError: bad argument type for built-in operation
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273709666.24.0.195793955891.issue8256@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is directly related to issue #6697. The first problem is that the builtin input() function doesn't check that _PyUnicode_AsString() result is not NULL.

The second problem is that io.StringIO().encoding is None. I don't understand why it is None whereas it uses utf8 (it calls TextIOWrapper constructor with encodings="utf8" and errors="strict").

I will be difficult to write an unit test because the issue only occurs if stdin and stdout are TTY: input() calls PyOS_Readline(stdin, stdout, prompt). 

--

@gruszczy: You're patch is just a workaround, not the right fix. The problem should be fixed in input(), not in PyUnicode methods. _PyUnicode_AsString() expects an unicode argument, it should raise an error if the argument is None (and not return a magical value).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Thu May 13 02:15:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 00:15:14 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273709714.34.0.798205068236.issue8256@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: TypeError: bad argument type for built-in operation -> input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Thu May 13 02:31:54 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Thu, 13 May 2010 00:31:54 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1273710714.66.0.760720175259.issue7978@psf.upfronthosting.co.za>


Changes by Yaniv Aknin <yaniv.aknin at gmail.com>:


Removed file: http://bugs.python.org/file16841/socketserver_eintr_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Thu May 13 02:32:56 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Thu, 13 May 2010 00:32:56 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1273710776.01.0.630270228535.issue7978@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

While bda's usecase is indeed fixed is recent versions, I want to point out the issue still exists in a recent py3k checkout. I've updated my patch to apply cleanly against recent py3k (and made less structural changes to test_socketserver.py; I still think it has an archaic unittest structure but I want this patch to remain relevant a bit longer, maybe fix the structure at a later time).

Again, I argue that resolving the general case (a generic untilConcludes to be exposed in stdlib) is hard and that we have a patch review worthy (IMO) solution at hand. Let's apply it (and possibly open a separate ticket for the generic case, if that's deemed interesting).

----------
Added file: http://bugs.python.org/file17314/socketserver_eintr_py3k_updated.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Thu May 13 02:56:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 00:56:06 +0000
Subject: [issue2716] Reimplement audioop because of copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1273712166.84.0.742225322566.issue2716@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I found severe bugs (which may lead to security vulnerabilities) in audioop: #7673. Nobody fixed these errors (but my issue contains a patch).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2716>
_______________________________________

From report at bugs.python.org  Thu May 13 02:57:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 00:57:45 +0000
Subject: [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1273712265.31.0.324757986236.issue4653@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Thu May 13 02:59:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 00:59:53 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273712393.33.0.46506250412.issue8678@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #7673 (other crashers).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Thu May 13 03:00:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:00:42 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1273712442.47.0.102437169363.issue8670@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Thu May 13 03:00:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:00:48 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1273712448.95.0.30413550032.issue8670@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Thu May 13 03:01:22 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Thu, 13 May 2010 01:01:22 +0000
Subject: [issue8538] Add ConfigureAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1273712482.52.0.969762266608.issue8538@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

I'm looking into making a patch from this for py3k, and have the following observations:

1. I agree with merwok, at the moment the monolithic ConfigureAction is a bit excessive for most uses (other than maybe emulating ./Configure...). I vote we split it to FlagAction and ConfigureAction.
2. I don't think this should be added as an argparse builtin/registered action (like action='store' or action='count'), but rather as a ready-made user-action in a separate namespace (from argparse.actions import FlagAction)

Given feedback that these two decisions seem sane, I'd be happy to produce a patch against recent py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Thu May 13 03:06:56 2010
From: report at bugs.python.org (Bryan Silverthorn)
Date: Thu, 13 May 2010 01:06:56 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1273712816.41.0.686437153722.issue7689@psf.upfronthosting.co.za>


Changes by Bryan Silverthorn <bcs26 at cornell.edu>:


----------
nosy: +bsilverthorn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Thu May 13 03:10:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:37 +0000
Subject: [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273713037.68.0.908216810922.issue8649@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8649>
_______________________________________

From report at bugs.python.org  Thu May 13 03:10:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:44 +0000
Subject: [issue8648] The UTF-7 codec functions are undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1273713044.03.0.561132088544.issue8648@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8648>
_______________________________________

From report at bugs.python.org  Thu May 13 03:10:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:50 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1273713050.07.0.0852734172688.issue8647@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Thu May 13 03:10:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:56 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1273713056.39.0.692179726274.issue8646@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Thu May 13 03:11:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:11:03 +0000
Subject: [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1273713063.06.0.0418700402669.issue8645@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8645>
_______________________________________

From report at bugs.python.org  Thu May 13 05:16:21 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 13 May 2010 03:16:21 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1273720581.51.0.765715071202.issue8591@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

I've started work on cleanup of ``mkpkg.py`` per instruction from jafo, am pushing to a branch 'mbh/mkpkg-cleanup' of my distutils2 fork:

    http://bitbucket.org/meatballhat/distutils2/changeset/be40174c59e2

I'll attach patch(es) when finished :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Thu May 13 05:49:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 13 May 2010 03:49:09 +0000
Subject: [issue8657] urlparse.urlunsplit should be smarter about +
In-Reply-To: <1273286948.85.0.868221921839.issue8657@psf.upfronthosting.co.za>
Message-ID: <1273722549.13.0.739996647501.issue8657@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I have added 'git' and 'git+ssh' under known schemes which will recognize authority/netloc and follow consistent round trip parsing behaviors.

For any unknown scheme(x or git+file), it might required to update the uses_netloc in the application.

git+ and svn+ might not be a good idea, as git+foobar like terms might cause ambiguity.

Fixed in r81130, r81131, r81132 and r81133.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8657>
_______________________________________

From report at bugs.python.org  Thu May 13 08:00:40 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 May 2010 06:00:40 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1273730440.02.0.480997496428.issue6610@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the test!  I'll take a look and likely commit this later.

----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________

From report at bugs.python.org  Thu May 13 09:04:31 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 13 May 2010 07:04:31 +0000
Subject: [issue8701] tarfile: first character of member names doubled
In-Reply-To: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>
Message-ID: <1273734271.32.0.78838020286.issue8701@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8701>
_______________________________________

From report at bugs.python.org  Thu May 13 09:13:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 13 May 2010 07:13:59 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1273734839.55.0.0567629415039.issue8678@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

haypo: what's the relationship?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Thu May 13 09:24:40 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 13 May 2010 07:24:40 +0000
Subject: [issue8699] Equality and hashing for functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1273735480.53.0.494653268412.issue8699@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Sorry, I realized I made a stupid mistake.  (I didn't use PyList_Sort to sort the list in partial_hash.)
Here is the corrected patch.

----------
Added file: http://bugs.python.org/file17315/partial_eq_hash_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8699>
_______________________________________

From report at bugs.python.org  Thu May 13 09:36:18 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 13 May 2010 07:36:18 +0000
Subject: [issue8701] tarfile: first character of member names doubled
In-Reply-To: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>
Message-ID: <1273736178.6.0.500125279974.issue8701@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Unfortunately, I cannot reproduce your problem and ask you to please provide more information. Would it be possible to attach the output or a screenshot depicting the problem? Which operating system/distribution do you use? Have you double-checked your testing conditions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8701>
_______________________________________

From report at bugs.python.org  Thu May 13 09:40:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 13 May 2010 07:40:22 +0000
Subject: [issue8673] configure script doesn't recognize 10.5 SDK correctly
In-Reply-To: <1273486329.72.0.388751753442.issue8673@psf.upfronthosting.co.za>
Message-ID: <1273736422.33.0.296271777904.issue8673@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The issue is indeed gone in HEAD. I've also verified the other 3 active branches.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8673>
_______________________________________

From report at bugs.python.org  Thu May 13 09:45:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 13 May 2010 07:45:43 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1273736743.7.0.167082465987.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached version should fix the issue found by Stefan. I'm going to do builds on OSX as well as Linux before committing though.

----------
Added file: http://bugs.python.org/file17316/issue7724-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Thu May 13 09:55:09 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 13 May 2010 07:55:09 +0000
Subject: [issue8126] Python 3.1.2rc1 doesn't compile using the 10.4 sdk on
	a	10.6 Mac
In-Reply-To: <1268415608.25.0.26520414202.issue8126@psf.upfronthosting.co.za>
Message-ID: <1273737309.54.0.182571063468.issue8126@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've verified that HEAD for both 3.1 and 3.2 build fine now, hence this issue can be closed.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8126>
_______________________________________

From report at bugs.python.org  Thu May 13 10:05:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 08:05:27 +0000
Subject: [issue8702] difflib: unified_diff produces wrong patches (again)
In-Reply-To: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>
Message-ID: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

If source/target file for unified format diff context doesn't end with new line, the diff should contain this marker:

\ No newline at end of file

Or else there is information loss when such patch is applied.

http://en.wikipedia.org/wiki/Diff#Unified_format

----------
components: Library (Lib)
messages: 105630
nosy: techtonik
priority: normal
severity: normal
status: open
title: difflib: unified_diff produces wrong patches (again)
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/issue8702>
_______________________________________

From report at bugs.python.org  Thu May 13 11:07:51 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 13 May 2010 09:07:51 +0000
Subject: [issue8455] buildbot: test_urllib2_localnet failures (Connection
	refused) on Tiger buildbot
In-Reply-To: <1271676544.68.0.615976232417.issue8455@psf.upfronthosting.co.za>
Message-ID: <1273741671.11.0.79319945491.issue8455@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8455>
_______________________________________

From report at bugs.python.org  Thu May 13 12:16:16 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 13 May 2010 10:16:16 +0000
Subject: [issue8703] Py3k PyList_Type documentation mentions types.ListType
In-Reply-To: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>
Message-ID: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The Py3k documentation of PyList_Type [1] contains the sentence:
"This is the same object as list and types.ListType in the Python layer."
But there is no types.ListType object in py3k.

[1] http://docs.python.org/dev/py3k/c-api/list.html#PyList_Type

----------
assignee: docs at python
components: Documentation
messages: 105631
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Py3k PyList_Type documentation mentions types.ListType
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8703>
_______________________________________

From report at bugs.python.org  Thu May 13 14:25:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 May 2010 12:25:18 +0000
Subject: [issue8702] difflib: unified_diff produces wrong patches (again)
In-Reply-To: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>
Message-ID: <1273753518.79.0.775867291418.issue8702@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8702>
_______________________________________

From report at bugs.python.org  Thu May 13 15:15:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 13 May 2010 13:15:52 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1273756552.21.0.164051899774.issue8422@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

afaict, it needs backport to 2.7.

----------
components: +Tests
nosy: +flox
stage:  -> commit review
status: closed -> open
type:  -> crash
versions: +Python 2.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Thu May 13 15:57:07 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 13 May 2010 13:57:07 +0000
Subject: [issue1481] test_uuid is warning about unreliable functions
In-Reply-To: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
Message-ID: <1273759027.87.0.364264462893.issue1481@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
_______________________________________

From report at bugs.python.org  Thu May 13 16:03:34 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 13 May 2010 14:03:34 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1273759414.72.0.283581933081.issue6419@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Thu May 13 16:12:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 13 May 2010 14:12:52 +0000
Subject: [issue8704] cgitb sends a bogus HTTP header if the app crashes before
	finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

If the CGI script crashes before finishing the headers, cgitb will emit invalid HTTP headers before showing the error message.  Below are HTTP headers I received, captured with a packet sniffer.  Note the "<--: spam".

HTTP/1.1 200 OK
Date: Thu, 13 May 2010 14:00:42 GMT
Server: Apache/2.2.9
<!--: spam
Vary: Accept-Encoding
Cache-Control: max-age=0
Expires: Thu, 13 May 2010 14:00:42 GMT
Set-Cookie: ref=; path=/; HttpOnly
Transfer-Encoding: chunked
Content-Type: text/html

That string it emitted by cgitb.reset(), which is trying to reset the browser to a sane state so the error message will be shown.  The problem can be easily fixed by having cgitb.reset() emit two CRLF pairs first, to ensure that we're done with the headers and emitting content:

-    return '''<!--: spam
+    return '''\r\n\r\n<!--: spam

----------
components: Library (Lib)
messages: 105633
nosy: stutzbach
priority: normal
severity: normal
status: open
title: cgitb sends a bogus HTTP header if the app crashes before finishing headers
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8704>
_______________________________________

From report at bugs.python.org  Thu May 13 16:12:58 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 13 May 2010 14:12:58 +0000
Subject: [issue8704] cgitb sends a bogus HTTP header if the app crashes before
	finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1273759978.07.0.26926680479.issue8704@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8704>
_______________________________________

From report at bugs.python.org  Thu May 13 16:14:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 14:14:58 +0000
Subject: [issue8702] difflib: unified_diff produces wrong patches (again)
In-Reply-To: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>
Message-ID: <1273760098.35.0.0628776656583.issue8702@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think difflib is behaving as intended here; changing to feature request.

Could you please clarify about the information loss?  I'm not seeing it.  As far as I can tell, the fact that unified_diff produces a list rather than a single string (as GNU diff effectively does) means that all necessary information about newlines is preserved, with no information loss:

newton:py3k dickinsm$ echo -n "one
two" > 1.txt
newton:py3k dickinsm$ echo -n "one
two         
" > 2.txt
newton:py3k dickinsm$ ./python.exe
Python 3.2a0 (py3k:81084:81085M, May 12 2010, 14:16:52) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from difflib import unified_diff
[47745 refs]
>>> list(unified_diff(list(open('1.txt')), list(open('2.txt'))))
['--- \n', '+++ \n', '@@ -1,2 +1,2 @@\n', ' one\n', '-two', '+two\n']
[53249 refs]

It looks to me as though the diff picks up the missing newline just fine.

The one problem with the above is that you can't do a ''.join() on it to give a meaningful diff, but I don't see that as a problem with the unified_diff function itself.

I'd be -1 on adding the "\ No newline at end of file" by default, since it complicates the unified_diff format unnecessarily (and would also affect backwards compatibility).  I wouldn't have any objections to an extra option for this, though.

----------
nosy: +mark.dickinson
stage:  -> unit test needed
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8702>
_______________________________________

From report at bugs.python.org  Thu May 13 16:54:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 14:54:53 +0000
Subject: [issue8702] difflib: unified_diff produces wrong patches (again)
In-Reply-To: <1273737926.93.0.83825384013.issue8702@psf.upfronthosting.co.za>
Message-ID: <1273762493.21.0.884308171572.issue8702@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It turns out that this problem was already reported in issue 2142 (which has a patch);  closing as a duplicate.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8702>
_______________________________________

From report at bugs.python.org  Thu May 13 16:55:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 14:55:21 +0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
	(same with context_diff)
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273762521.04.0.180975846747.issue2142@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closed 8702 as a duplicate of this one.  Combining nosy lists.

----------
nosy: +mark.dickinson, techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Thu May 13 16:55:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 14:55:34 +0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
	(same with context_diff)
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273762534.5.0.226742290781.issue2142@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Thu May 13 17:36:47 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 13 May 2010 15:36:47 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1273765007.45.0.854635422684.issue7449@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Victor, I think one more skip is required in test_socketserver.

----------
nosy: +skrah
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file17317/nothreads-socketserver-shutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Thu May 13 18:01:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 16:01:29 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273766489.32.0.371280472281.issue2142@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

You mean that this patch sits in here for 2 years already? This suxx.

And nobody added the tag 'easy', because people haven't explicitly requested tracker privileges? That suxx. 

And it won't be in 2.7 because of that.. I am disappointed.

Why this issue is not labeled as 'difflib' related? How are people supposed to find this one?

----------
title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff) -> difflib.unified_diff(...) produces invalid patches

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Thu May 13 18:03:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 16:03:10 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273766590.72.0.822238785723.issue2142@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Trent, the "\ New line..." seems to be feature specific to unified format only. http://en.wikipedia.org/wiki/Diff#Unified_format

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Thu May 13 18:20:20 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 16:20:20 +0000
Subject: [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>
Message-ID: <1273767620.13.0.0983524936652.issue4898@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Another 'easy' patch hangs for ages. =/

tag:easy
tag:difflib

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4898>
_______________________________________

From report at bugs.python.org  Thu May 13 18:24:28 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 16:24:28 +0000
Subject: [issue7585] difflib should separate filename from timestamp with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1273767868.16.0.349339766875.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

tag:difflib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7585>
_______________________________________

From report at bugs.python.org  Thu May 13 18:26:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 16:26:13 +0000
Subject: [issue8422] tiger buildbot: test_abspath_issue3426 failure
	(test_genericpath.py)
In-Reply-To: <1271435466.82.0.847060352272.issue8422@psf.upfronthosting.co.za>
Message-ID: <1273767973.83.0.862456907993.issue8422@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> afaict, it needs backport to 2.7.

Right: r81135 (and r81137).

Blocked on 2.6 (it doesn't have the non-ASCII path test): r81139.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8422>
_______________________________________

From report at bugs.python.org  Thu May 13 18:27:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 13 May 2010 16:27:10 +0000
Subject: [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>
Message-ID: <1273768030.71.0.92867814052.issue4898@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks for the patch. This was fixed as part of issue 7585.

Please add issue 7585 as superceder and close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4898>
_______________________________________

From report at bugs.python.org  Thu May 13 18:27:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 13 May 2010 16:27:42 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1273768062.01.0.0199999299156.issue8084@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It fails on "x86 Tiger trunk" buildbot, too.
(the PPC Tiger buildbot is happy)

----------
keywords: +buildbot
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Thu May 13 18:39:50 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 13 May 2010 16:39:50 +0000
Subject: [issue8699] Equality and hashing for functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1273768790.04.0.453589133074.issue8699@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

On python-dev Yaniv Aknin pointed out that the keywords dictionary of a partial object is mutable [1].  This causes problems with hashing and equality.  The new patch replaces the keywords dictionary with a read-only proxy of that dictionary.  This seems to solve the problem. 

[1] http://mail.python.org/pipermail/python-dev/2010-May/100059.html

----------
Added file: http://bugs.python.org/file17318/partial_eq_hash_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8699>
_______________________________________

From report at bugs.python.org  Thu May 13 18:57:24 2010
From: report at bugs.python.org (Dan Koch)
Date: Thu, 13 May 2010 16:57:24 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>


New submission from Dan Koch <kochdb at ornl.gov>:

The following sequence raises an exception, but nonetheless removes all files from the Desktop under Windows Vista.

import os, shutil, user

desktop_dir = os.path.join(user.home, 'Desktop')
os.chdir(desktop_dir)

shutil.rmtree('')

This does not occur under Fedora 12. Not tested on Mac OS X yet.

----------
components: Windows
messages: 105646
nosy: dbkoch
priority: normal
severity: normal
status: open
title: shutil.rmtree with empty filepath
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Thu May 13 19:20:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 17:20:20 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273771220.27.0.558041831637.issue2142@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Not in my version of diff:  it seems to use '\ No newline at end of file' for both unified and 'normal' diffs.

$ diff --version
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.
...

$ diff 1.txt 2.txt
2c2
< two
\ No newline at end of file
---
> two

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Thu May 13 19:31:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 13 May 2010 17:31:02 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1273771862.33.0.512538928484.issue8423@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh, Tests
nosy: +flox, mark.dickinson, michael.foord, ned.deily, ronaldoussoren
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Thu May 13 19:56:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 13 May 2010 17:56:26 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1273773386.65.0.177344366003.issue8423@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Some diagnosis information ...

 - happens for 2 tests inside test_pep277: test_listdir and test_normalize
 - happens only for 4 weird filenames (added with #8180)
 - happens only on "x86 Tiger" buildbot ("PPC Tiger" does not report this error)

I've added some lines to regrtest.py to identify each platform:
"x86 Tiger": Darwin-8.10.1-i386-32bit little-endian (OS X 10.4.10)
"PPC Tiger": Darwin-8.11.0-Power_Macintosh-powerpc-32bit big-endian (OS X 10.4.11)

I don't know how the endianness may be linked with this issue.


Failing files (4):
    u'\u0385\u03d3\u03d4',
    u'\u00a8\u0301\u03d2\u0301\u03d2\u0308',    # == NFD(u'\u0385\u03d3\u03d4')
    u'\u0020\u0308\u0301\u038e\u03ab',          # == NFKC(u'\u0385\u03d3\u03d4')
    u'\u1e9b\u1fc1\u1fcd\u1fce\u1fcf\u1fdd\u1fde\u1fdf\u1fed',


One solution is to skip these files on all 'darwin' platforms, without losing more time on this issue.

----------
assignee: ronaldoussoren -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Thu May 13 20:06:03 2010
From: report at bugs.python.org (Poor Yorick)
Date: Thu, 13 May 2010 18:06:03 +0000
Subject: [issue8701] tarfile: first character of member names doubled
In-Reply-To: <1273699179.4.0.239975221626.issue8701@psf.upfronthosting.co.za>
Message-ID: <1273773963.63.0.0741919186563.issue8701@psf.upfronthosting.co.za>


Poor Yorick <pooryorick at users.sourceforge.net> added the comment:

I can't reproduce it now, either.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8701>
_______________________________________

From report at bugs.python.org  Thu May 13 20:31:37 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 13 May 2010 18:31:37 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1273775497.49.0.0723445656902.issue3605@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Fixed in r81142.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu May 13 20:43:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 13 May 2010 18:43:33 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1273776213.62.0.652865996507.issue8423@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

It prefer if it were clear why these tests fail (but don't have time to look into this at the moment). That is, I don't mind if the tests get disabled on darwin, but only if there is a documented reason for it because otherwise disabling the test might hide a real issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Thu May 13 21:10:55 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 May 2010 19:10:55 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

C Python has a real wart in that standard types and library functions that are implemented in C do not always accept keyword arguments:

>>> 'xxxxxx'.find('xx', 4)
4
>>> 'xxxxxx'.find('xx', start=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: find() takes no keyword arguments
>>> 

While other things do accept keywords:

sorted(s, key=bla)


We should clean this up.  It is not well documented anywhere and I suspect other python implementations (haven't tested this) may accept keywords on these where C Python doesn't.

In string.find()'s case it looks like this is because it is an old style C method declaration that only gets an args tuple, no keyword args dict.

----------
messages: 105652
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: accept keyword arguments on all base type methods and builtins
type: feature request
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Thu May 13 21:35:29 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 13 May 2010 19:35:29 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273779329.13.0.0285901169814.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

After experimenting with changing the order of the multiplications and not having much luck, I went back and looked for other differences in Alexander's Python functions that might cause the speed difference.  I believe partial_product2 is fast because it performs all of its operations in-place using a single list, whereas partial_product3 creates a new list during each iteration.  Here's a version of partial_product3 that operates in-place and is just as fast as partial_product2:

def partial_product3(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    n = len(a)
    while 1:
        if n == 1:
            return a[0]
        half = n//2
        for k in range(0,half):
            a[k] = a[k*2] * a[k*2+1]
        if n & 1:
            a[half] = a[n-1]
        n = half

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 22:29:57 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Thu, 13 May 2010 20:29:57 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273782597.77.0.436531583202.issue8689@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

I wrote a Perl script testing this issue and it fails too, so it's most probably a bug in sqlite itself.  I think the bug is already reported under id 26ff0c82d1 in sqlite bug tracker: http://www.sqlite.org/src/rptview?rn=2

----------
nosy: +marcin.bachry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Thu May 13 22:57:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 May 2010 20:57:03 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273784223.74.0.00521608011996.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Daniel,

Your variant does not seem to work:

>>> def partial_product3(j, i):
...     a = [l << 1 | 1 for l in range(j, i + 1)]
...     n = len(a)
...     while 1:
...         if n == 1:
...             return a[0]
...         half = n//2
...         for k in range(0,half):
...             a[k] = a[k*2] * a[k*2+1]
...         if n & 1:
...             a[half] = a[n-1]
...         n = half

>>> partial_product3(4,6)
99
>>> 9 * 11 * 13
1287

but it looks like I posted a buggy version of partial_product2 as well.  Strange because I thought I had enough doctests to catch the errors.  I'll redo the testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 23:10:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 21:10:22 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1273785022.02.0.930366439933.issue8670@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Support of characters outside the Unicode BMP (code > 0xffff) is not complete in narrow build (sizeof(Py_UNICODE) == 2) for Python2:

$ ./python
Python 2.7b2+ (trunk:81139M, May 13 2010, 18:45:37) 
>>> x=u'\U00010000'
>>> x[0], x[1]
(u'\ud800', u'\udc00')
>>> len(x)
2
>>> ord(x)
Traceback (most recent call last):
  ...
TypeError: ord() expected a character, but string of length 2 found
>>> unichr(0x10000)
Traceback (most recent call last):
  ...
ValueError: unichr() arg not in range(0x10000) (narrow Python build)

It looks better in Python3:

$ ./python 
Python 3.2a0 (py3k:81137:81138, May 13 2010, 18:50:51) 
>>> x='\U00010000'
>>> x[0], x[1]
('\ud800', '\udc00')
>>> len(x)
2
>>> ord(x)
65536
>>> chr(0x10000)
'\U00010000'

About the issue, the problem is in function u_set(). This function should use PyUnicode_AsWideChar() but PyUnicode_AsWideChar() doesn't support surrogates... whereas PyUnicode_FromWideChar() does support surrogates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Thu May 13 23:13:35 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 13 May 2010 21:13:35 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273785215.48.0.563755383228.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Isn't it amazing how fast one can make incorrect code? ;-)

Here is a fixed version of my partial_product3, but now it is no faster than partial_product.

def partial_product3(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    n = len(a)
    while 1:
        if n == 1:
            return a[0]
        half = n//2
        for k in range(0,half):
            a[k] = a[k*2] * a[k*2+1]
        if n & 1:
            a[half] = a[n-1]
            n = half + 1
        else:
            n = half

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 23:14:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 May 2010 21:14:39 +0000
Subject: [issue8703] Py3k PyList_Type documentation mentions types.ListType
In-Reply-To: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>
Message-ID: <1273785279.71.0.995468130569.issue8703@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81145. Thanks.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8703>
_______________________________________

From report at bugs.python.org  Thu May 13 23:21:03 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 13 May 2010 21:21:03 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1273785663.75.0.104528819086.issue1100562@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Unit tests added; tested both on python2.6 and python2.7.

----------
nosy: +maker
versions: +Python 2.6
Added file: http://bugs.python.org/file17319/issue1100562.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100562>
_______________________________________

From report at bugs.python.org  Thu May 13 23:28:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 21:28:08 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273786088.25.0.951000165501.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Does anyone feel like doing a speed comparison between Daniel's C patch and a version with a direct no-frills iterative version of factorial_part_product (i.e., just a simple  'for (i = n; i <= m; i += 2) { <multiply running product by i> }?  I have a sneaking suspicion that the iterative version will be faster even for quite large values of n, but I'd be happy to be proven wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 23:31:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 21:31:36 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273786296.56.0.111300439078.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And why are we trying to speed up the pure Python factorial code here?  I don't imagine that those speed differences are going to translate well to C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 23:47:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 21:47:38 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1273787258.01.0.0934438134741.issue8423@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It prefer if it were clear why these tests fail

I agree.  There's little point having tests if we're just going to disable them when they fail without understanding why they're failing first.

At that point a green buildbot just means "Hey, we disabled all failing tests!", rather than being an indication that Python's working well on that platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Thu May 13 23:50:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 May 2010 21:50:48 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273786296.56.0.111300439078.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTimpBZCCUoBVQu9o3uLadXBvoaSLaaZoZ9VHOIzo@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, May 13, 2010 at 5:31 PM, Mark Dickinson <report at bugs.python.org> wrote:
> And why are we trying to speed up the pure Python factorial code here?

I would expect that for large factorials the performance will be
determined by the number of long multiplications and the size of
multiplicands.

>??I don't imagine that those speed differences are going to translate well to C.

The differences between recursive and non-recursive versions are not
likely to translate well, but the difference (if any) between the
order of multiplication most likely will.

In any case, I am attaching fixed version of factorial4.

$ ./python.exe -m timeit -s "from factorial4 import f0 as f" "f(10000)"
10 loops, best of 3: 65.5 msec per loop
$ ./python.exe -m timeit -s "from factorial4 import f1 as f" "f(10000)"
10 loops, best of 3: 66.9 msec per loop
$ ./python.exe -m timeit -s "from factorial4 import f2 as f" "f(10000)"
10 loops, best of 3: 56.5 msec per loop
$ ./python.exe -m timeit -s "from factorial4 import f3 as f" "f(10000)"
10 loops, best of 3: 63 msec per loop

----------
Added file: http://bugs.python.org/file17320/factorial4.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
import functools
import operator

product = functools.partial(functools.reduce, operator.mul)


def partial_product(j, i):
    if i == j:
        return j << 1 | 1
    if i == j + 1:
        return (j << 1 | 1) * (i << 1 | 1)
    l = i + j >> 1
    return partial_product(j, l) * partial_product(l + 1, i)

def naive_factorial(n):
    """Naive implementation of factorial: product([1, ..., n])

    >>> naive_factorial(4)
    24
    """
    return product(range(1, n+1), 1)

def factorial(n, pp=partial_product):
    """Implementation of Binary-Split Factorial algorithm

    See http://www.luschny.de/math/factorial/binarysplitfact.html

    >>> for n in range(20):
    ...     assert(factorial(n) == naive_factorial(n))
    >>> import math
    >>> assert(factorial(100) == math.factorial(100))
    """
    _, r = loop(n, pp)
    return r << (n - count_bits(n))

def loop(n, pp):
    p = r = 1
    for i in range(n.bit_length() - 2, -1, -1):
        m = n >> i
        if m > 2:
            p *= pp(((m >> 1) + 1) >> 1, (m - 1) >> 1)
            r *= p
    return p, r

def partial_product1(j, i):
    return product((l << 1 | 1 for l in range(j, i + 1)), 1)

def partial_product2(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    n = i - j + 1
    p = 1
    while n > 1:
        for k in range(n>>1):
            a[k] *= a[n-k-1]
        n = (n>>1) + (n&1)
    return a[0]

def partial_product3(j, i):
    a = [l << 1 | 1 for l in range(j, i + 1)]
    while 1:
        n = len(a)
        if n == 1:
            return a[0]
        a = [a[k<<1] * a[k<<1|1] for k in range(n>>1)] + a[(n >> 1)<<1:]

def partial_product4(j, i):
    if i == j:
        return j << 1 | 1
    if i == j + 1:
        return (j << 1 | 1) * (i << 1 | 1)
    return (j << 1 | 1) * (i << 1 | 1) * partial_product4(j + 1, i - 1)


def count_bits(n):
    count = 0
    while n:
        n &= n - 1
        count += 1
    return count

def f0(n):
    return factorial(n)

def f1(n):
    return factorial(n, partial_product1)

def f2(n):
    return factorial(n, partial_product2)

def f3(n):
    return factorial(n, partial_product3)


if __name__ == '__main__':
    for n in list(range(12, 20)) + [100, 101, 200]:
        assert(f0(n) == f1(n) == f2(n) == f3(n))
    import doctest
    doctest.testmod()

From report at bugs.python.org  Thu May 13 23:57:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 May 2010 21:57:53 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273787873.85.0.37005436606.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17313/factorial4.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Thu May 13 23:58:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 May 2010 21:58:48 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273787928.79.0.0765796576975.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I would expect that for large factorials the performance will be
> determined by the number of long multiplications and the size of
> multiplicands.

Okay, but I don't think we should care about the performance of *really* large factorials for Python.  People who care about every bit of speed in that situation should be using GMP or something similar.  An optimization that only makes a difference for (say) factorial(50000) or higher isn't going to make much difference to most Python users.  Optimizations that speed up, say, factorial(n) for n <= 1000 would seem more valuable.

> The differences between recursive and non-recursive versions are not
> likely to translate well, but the difference (if any) between the
> order of multiplication most likely will.

Perhaps.  But the differences between the various Python versions here are small enough that they could easily be swamped by other factors involved in the Python-to-C translation.

We already have a working C patch here (modulo minor issues), and I'd like to move forward with that patch;  I think this issue discussion is getting a bit side-tracked.

grumpily-yours...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 00:09:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 13 May 2010 22:09:07 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273788547.25.0.612184566517.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Speaking of getting side-tracked, I didn't see an answer to a question I asked earlier.  I'd like to get some feedback before I proceed with revising the patch.

For the find-last-set-bit (to replace log2) and count-set-bits operations, would it be worthwhile to create a pybits.h and .c that defines _Py_FindLastSetBit and _Py_CountSetBits? (with appropriate logic in the .h and configure.in to use system/compiler versions if available)

There are already two implementations of find-last-set-bit in Python:
bits_in_digit() in Objects/longobject.c and hi0bits() in Python/dtoa.c, which I could consolidate.

Alternately, I could just add static functions to mathmodule.c with the simplest possible implementation (they're only called once per factorial, so the performance impact is minimal).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 00:37:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 May 2010 22:37:17 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273788547.25.0.612184566517.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTimVqlOvOolIABp2BjdDQlAW3rNfMmEkHR1TVaWA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, May 13, 2010 at 6:09 PM, Daniel Stutzbach
<report at bugs.python.org> wrote:
..
> Speaking of getting side-tracked, I didn't see an answer to a question I asked
> earlier. ?I'd like to get some feedback before I proceed with revising the patch.

I did not respond because I don't have an answer. :-)  Maybe it is
time to revisit Raymond's reasoning in msg63969 where he argued that
factorial should be an int method because it would benefit from access
to integer implementation details.

He also argued that
"""
Compared to  numbits() and isqrt(), a factorial() method is more basic
in that it is self explanatory and everyone knows what it means by the
time they are in middle school.
"""
nevertheless numbits() aka bit_length() has become an int method, but
factorial landed in math.

>
> For the find-last-set-bit (to replace log2) and count-set-bits operations, would it
> be worthwhile to create a pybits.h and .c that defines _Py_FindLastSetBit and >_Py_CountSetBits? (with appropriate logic in the .h and configure.in to use
> system/compiler versions if available)

Since it is unlikely that either factorial() or bit_length() will be
moved from their current location, I would be +1 on creating pybits.
I would give them different names, though.  Popcount seems to be the
most popular name for CountSetBits and instead of FindLastSetBit, a
more common function seems to be nlz, number of leading zeros.  On the
other hand, since  bit_length is already established, maybe
_Py_bit_length_long(long) and (if needed) _Py_bit_length_int(int)
would make sense.

>
> There are already two implementations of find-last-set-bit in Python:
> bits_in_digit() in Objects/longobject.c and hi0bits() in Python/dtoa.c,
> which I could consolidate.

How did you find it?!  I hope we'll end up with a better name than that.

>
> Alternately, I could just add static functions to mathmodule.c with the simplest
> possible implementation (they're only called once per factorial, so the
> performance impact is minimal).

In the scope of this issue I would say do that.  Pybits proposal seem
to deserve it's own issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 01:27:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 13 May 2010 23:27:01 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1273793221.53.0.378646565668.issue1100562@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib) -None
nosy: +ezio.melotti
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100562>
_______________________________________

From report at bugs.python.org  Fri May 14 01:36:31 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 13 May 2010 23:36:31 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/telnetlib.html#telnetlib.Telnet

The part "number can be passed to the constructor... " is duplicated.

----------
assignee: docs at python
components: Documentation
messages: 105667
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Duplicated document in telnetlib.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Fri May 14 01:40:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 13 May 2010 23:40:22 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273693664.96.0.298446297195.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTik1JBdgs0vk-87MABS3HFxavO0DjG1XH887FB95@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, May 12, 2010 at 3:47 PM, Mark Dickinson <report at bugs.python.org> wrote:
>...
> Realistically though, I don't see an iterative version of factorial_part_product as
> an option for the C patch, without a significant increase in complexity. ??Daniel's
> current patch is remarkably clean and simple, and I'd like to keep it that way.
>

I am attaching an iterative version in C patch.  I don't think it
represents a dramatic increase in complexity ~ 40 lines over Daniel's
30.

> I did think about various evil schemes for an iterative version, ...

I would not say my patch is evil, maybe a bit naughty. :-) It can be
made less evil by resizing the list instead of filling its tail with
NULLs or more evil by using a tuple instead of list.

The performance  appears to be identical to Daniel's with no small
integer multiplication optimization.  The later gives about 2%
improvement.

----------
Added file: http://bugs.python.org/file17321/factorial-no-recursion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
Index: Modules/mathmodule.c
===================================================================
--- Modules/mathmodule.c	(revision 81150)
+++ Modules/mathmodule.c	(working copy)
@@ -1129,56 +1129,173 @@
 Return an accurate floating point sum of values in the iterable.\n\
 Assumes IEEE-754 floating point arithmetic.");
 
+/* Divide-and-conquer factorial algorithm
+ *
+ * Based on the formula and psuedo-code provided at:
+ * http://www.luschny.de/math/factorial/binarysplitfact.html
+ *
+ * Faster algorithms exist, but they're more complicated and depend on
+ * a fast prime factoriazation algorithm.
+ */
+
+/* i-th odd number */
+#define ODD(i) (i << 1 | 1) 
+/* Compute product(ODD(i) for i in range(first, last+1)) */
 static PyObject *
+factorial_partial_product(unsigned long first, unsigned long last)
+{
+    PyObject *result;
+    PyObject *a, *x, *y;
+    Py_ssize_t n, i;
+
+    n = last - first + 1;
+    if (n <= 0)
+	return PyLong_FromLong(1L);
+    if (n == 1)
+	return PyLong_FromUnsignedLong(ODD(first));
+
+    /* a = [ODD(i) for i in range(first, last + 1)] */
+    a = PyList_New(last - first + 1);
+    if (a == NULL)
+	return NULL;
+    for  (i = 0; i < n; ++i) {
+	result = PyLong_FromUnsignedLong(ODD(first + i));
+	if (result == NULL)
+	    goto done;
+	PyList_SET_ITEM(a, i, result);
+    }
+    while (n > 1) {
+	for (i = (n >> 1) - 1; i >= 0; --i) {
+	    x = PyList_GET_ITEM(a, i);
+	    y = PyList_GET_ITEM(a, n - i - 1);
+	    result = PyNumber_Multiply(x, y);
+	    if (result == NULL)
+		goto done;
+	    PyList_SET_ITEM(a, i, result);
+	    PyList_SET_ITEM(a, n - i - 1, NULL);
+	    Py_DECREF(x);
+	    Py_DECREF(y);
+	}
+	n = (n >> 1) + (n & 1);
+    }
+    /* Release reference held by the list */
+    PyList_SET_ITEM(a, 0, NULL);
+ done:
+    Py_DECREF(a);
+    return result;
+}
+
+static unsigned long
+bit_length(unsigned long n)
+{
+    unsigned long len = 0;
+    while (n != 0) {
+	++len;
+	n >>= 1;
+    }
+    return len;
+}
+
+static unsigned long
+bit_count(unsigned long n)
+{
+    unsigned long count = 0;
+    while (n != 0) {
+	++count;
+	n &= n - 1; /* clear least significant bit */
+    }
+    return count;
+}
+
+static PyObject *
+factorial_loop(unsigned long n)
+{
+    long i, v;
+    PyObject *p, *r;
+    PyObject *part, *tmp;
+
+    p = PyLong_FromLong(1L);
+    if (p == NULL)
+        return NULL;
+    Py_INCREF(p);
+    r = p;
+
+    for (i = bit_length(n) - 2; i >= 0; --i) {
+        v = n >> i;
+        if (v > 2) {
+	    part = factorial_partial_product(((v >> 1) + 1) >> 1, (v - 1) >> 1);
+	    if (part == NULL)
+		goto error;
+
+	    tmp = PyNumber_Multiply(p, part);
+	    Py_DECREF(part);
+	    if (tmp == NULL)
+		goto error;
+	    Py_DECREF(p);
+	    p = tmp;
+
+	    tmp = PyNumber_Multiply(r, p);
+	    if (tmp == NULL)
+		goto error;
+	    Py_DECREF(r);
+	    r = tmp;
+	}
+    }
+    Py_DECREF(p);
+    return r;
+ error:
+    Py_DECREF(p);
+    Py_DECREF(r);
+    return NULL;
+}
+
+static PyObject *
 math_factorial(PyObject *self, PyObject *arg)
 {
-    long i, x;
-    PyObject *result, *iobj, *newresult;
+    PyObject *result;
 
+    PyObject *r; /* result without trailing zeros */
+    PyObject *ntz; /* number of trailing zeros */
+    long n;
+
     if (PyFloat_Check(arg)) {
-        PyObject *lx;
         double dx = PyFloat_AS_DOUBLE((PyFloatObject *)arg);
         if (!(Py_IS_FINITE(dx) && dx == floor(dx))) {
             PyErr_SetString(PyExc_ValueError,
                 "factorial() only accepts integral values");
             return NULL;
         }
-        lx = PyLong_FromDouble(dx);
-        if (lx == NULL)
+        n = (long) dx;
+    } else {
+        n = PyLong_AsLong(arg);
+        if (n == -1 && PyErr_Occurred())
             return NULL;
-        x = PyLong_AsLong(lx);
-        Py_DECREF(lx);
     }
-    else
-        x = PyLong_AsLong(arg);
 
-    if (x == -1 && PyErr_Occurred())
-        return NULL;
-    if (x < 0) {
+    if (n < 0) {
         PyErr_SetString(PyExc_ValueError,
-            "factorial() not defined for negative values");
+                        "factorial() not defined for negative values");
         return NULL;
     }
 
-    result = (PyObject *)PyLong_FromLong(1);
-    if (result == NULL)
+    if (n <= 12) {
+        static const long lookup[] = {1, 1, 2, 6, 24, 120, 720, 5040, 40320,
+                                      362880, 3628800, 39916800, 479001600};
+        return PyLong_FromLong(lookup[n]);
+    }
+
+    r = factorial_loop(n);
+    if (r == NULL)
         return NULL;
-    for (i=1 ; i<=x ; i++) {
-        iobj = (PyObject *)PyLong_FromLong(i);
-        if (iobj == NULL)
-            goto error;
-        newresult = PyNumber_Multiply(result, iobj);
-        Py_DECREF(iobj);
-        if (newresult == NULL)
-            goto error;
-        Py_DECREF(result);
-        result = newresult;
+
+    ntz = PyLong_FromLong(n - bit_count(n));
+    if (ntz != NULL) {
+	result = PyNumber_Lshift(r, ntz);
+	Py_DECREF(ntz);
     }
+
+    Py_DECREF(r);
     return result;
-
-error:
-    Py_DECREF(result);
-    return NULL;
 }
 
 PyDoc_STRVAR(math_factorial_doc,

From report at bugs.python.org  Fri May 14 01:42:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 13 May 2010 23:42:22 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1273794142.77.0.837128870246.issue8423@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The gory details...

>>> import os, unicodedata
>>> tempdir = u'temp_pep277'
>>> name = u'\u0385\u03d3\u03d4'
>>> os.mkdir(tempdir)
>>> with open(os.path.join(tempdir, name), 'w') as f:
...     f.write('foo')
>>> unicodedata.normalize('NFD', name)
u'\xa8\u0301\u03d2\u0301\u03d2\u0308'
>>> os.listdir(tempdir)
[u'\xa8\u0301\u03d2\u03d2\u0301\u0308']

The filename should use the Normal Decomposition (NFD) of the original filename. But the decomposition looks wrong on this platform.

The problem is similar for the other special filenames. Examples:
- u'\u0385\u03d3\u03d4'
 ==> NFD: u'\xa8\u0301\u03d2\u0301\u03d2\u0308'
 ==> OSX: u'\xa8\u0301\u03d2\u03d2\u0301\u0308'
- u' \u0308\u0301\u038e\u03ab'
 ==> NFD: u' \u0308\u0301\u03a5\u0301\u03a5\u0308'
 ==> OSX: u' \u0308\u0301\u03a5\u03a5\u0301\u0308'
- u'\u1e9b\u1fc1\u1fcd\u1fce\u1fcf\u1fdd\u1fde\u1fdf\u1fed'
 ==> NFD: u'\u017f\u0307\xa8\u0342\u1fbf\u0300\u1fbf\u0301\u1fbf\u0342\u1ffe\u0300\u1ffe\u0301\u1ffe\u0342\xa8\u0300'
 ==> OSX: u'\u017f\u0307\xa8\u0342\u1fbf\u0300\u1fbf\u0301\u1fbf\u1ffe\u1ffe\u1ffe\xa8\u0342\u0300\u0301\u0342\u0300'

I have no idea how to investigate further.
And the "PPC Tiger" buildbot does not fail here.

Reference about OSX decomposition:
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Fri May 14 01:56:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 23:56:54 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1273795014.34.0.614697096414.issue8670@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch for Python3:
 - Fix PyUnicode_AsWideChar() to support surrogates (Py_UNICODE: 2 bytes, wchar_t: 4 bytes)
 - u_set() of _ctypes uses PyUnicode_AsWideChar()
 - add a test (skipped if sizeof(wchar_t) is smaller than 4 bytes)

It's too late to fix Python2: 2.7 beta 2 was released (it doesn't support non BMP characters for chr()/ord()).

TODO:
 - I'm not sure that my patch on PyUnicode_AsWideChar() works if sizeof(wchar_t)==2
 - Test the patch on Windows
 - Check that it doesn't break other functions calling PyUnicode_AsWideChar()

ctypes, _locale.strcoll() and time.strftime() use PyUnicode_AsWideChar(). time has interesting comments:

    /* This assumes that PyUnicode_AsWideChar doesn't do any UTF-16
       expansion. */
    if (PyUnicode_AsWideChar((PyUnicodeObject*)format,
                             (wchar_t*)PyBytes_AS_STRING(tmpfmt),
                             PyUnicode_GetSize(format)+1) == (size_t)-1)
        /* This shouldn't fail. */
        Py_FatalError("PyUnicode_AsWideChar failed");

----------
keywords: +patch
Added file: http://bugs.python.org/file17322/pyunicode_aswidechar_surrogates-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8670>
_______________________________________

From report at bugs.python.org  Fri May 14 02:40:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 14 May 2010 00:40:47 +0000
Subject: [issue8584] test_multiprocessing skips some tests
In-Reply-To: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>
Message-ID: <1273797647.32.0.19210607598.issue8584@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Value and copy come from multiprocessing.sharedctypes, not from ctypes. Changed the import and also the test skipping based on this.

(done during a presentation with the Chicago Python Users Group)

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file17323/issue8584.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8584>
_______________________________________

From report at bugs.python.org  Fri May 14 02:41:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 14 May 2010 00:41:48 +0000
Subject: [issue8584] test_multiprocessing skips some tests
In-Reply-To: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>
Message-ID: <1273797708.96.0.796141184765.issue8584@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8584>
_______________________________________

From report at bugs.python.org  Fri May 14 02:42:25 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 14 May 2010 00:42:25 +0000
Subject: [issue8708] OpenID blunder
In-Reply-To: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>
Message-ID: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>


New submission from Jack Diederich <jackdied at gmail.com>:

I tried logging into the tracker using my gmail login and accidentally
created a new user.  Could someone either wipe out the OpenID for
jackdied at gmail.com (but NOT the "jackdied" login with email addy of
jackdied at gmail.com) or combine the two?

In the end I just reset my password and logged in as the original "jackdied"

TIA,

-Jack

----------
messages: 105672
nosy: Jack.Diederich
priority: normal
severity: normal
status: open
title: OpenID blunder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8708>
_______________________________________

From report at bugs.python.org  Fri May 14 02:43:12 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 14 May 2010 00:43:12 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273797792.94.0.10923784681.issue8707@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


----------
assignee: docs at python -> jackdied
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Fri May 14 02:44:32 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 14 May 2010 00:44:32 +0000
Subject: [issue8708] OpenID blunder
In-Reply-To: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>
Message-ID: <1273797872.5.0.906940372292.issue8708@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Woops, didn't know that email would create a new bug.

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8708>
_______________________________________

From report at bugs.python.org  Fri May 14 02:46:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 00:46:24 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1273794142.77.0.837128870246.issue8423@psf.upfronthosting.co.za>
Message-ID: <201005140246.16312.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Reference about OSX decomposition:
> http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

Mac OS X source code:
http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/vfs/vfs_utfconv.c?txt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Fri May 14 03:00:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 01:00:16 +0000
Subject: [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1273798816.88.0.0731308132449.issue4653@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed the typo in pythonrun.c: r81156. I don't use Windows, so I cannot review the other fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Fri May 14 03:20:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 01:20:15 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1273709714.4.0.35932325802.issue8256@psf.upfronthosting.co.za>
Message-ID: <201005140317.33456.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch catching the _PyUnicode_AsString() error.

input() uses sys.stdout.encoding to encode the prompt to a byte string, but 
PyOS_StdioReadline() writes the prompt to stderr (it should use sys_stdout).

I don't know which encoding should be used if sys.stdout.encoding is None (eg. 
if sys.stdout is a StringIO() object).

StringIO() of _io module has no encoding because it stores unicode characters, 
not bytes. StringIO() of _pyio module is based on BytesIO() and use utf8 
encoding, but the reference implementation is now _io.

----------
Added file: http://bugs.python.org/file17324/input_stdout_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________
-------------- next part --------------
Index: Python/bltinmodule.c
===================================================================
--- Python/bltinmodule.c	(r??vision 81157)
+++ Python/bltinmodule.c	(copie de travail)
@@ -1618,6 +1618,7 @@
         if (promptarg != NULL) {
             PyObject *stringpo;
             PyObject *stdout_encoding;
+            char *stdout_encoding_str;
             stdout_encoding = PyObject_GetAttrString(fout,
                                                      "encoding");
             if (stdout_encoding == NULL) {
@@ -1630,8 +1631,17 @@
                 Py_DECREF(stdout_encoding);
                 return NULL;
             }
+            if (stdout_encoding != Py_None)
+                stdout_encoding_str = _PyUnicode_AsString(stdout_encoding);
+            else
+                stdout_encoding_str = "utf-8";
+            if (stdout_encoding_str == NULL) {
+                Py_DECREF(stdin_encoding);
+                Py_DECREF(stdout_encoding);
+                return NULL;
+            }
             po = PyUnicode_AsEncodedString(stringpo,
-                _PyUnicode_AsString(stdout_encoding), NULL);
+                                           stdout_encoding_str, NULL);
             Py_DECREF(stdout_encoding);
             Py_DECREF(stringpo);
             if (po == NULL) {

From report at bugs.python.org  Fri May 14 03:30:15 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 May 2010 01:30:15 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1273800615.91.0.377856289583.issue5099@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, my patch is committed:

 2.6 81158
 2.7 81154
 3.1 81159
 3.2 81155

I didn't apply your test, Gabriel, as it passed without the fixes. Thanks to the work you did on it, though.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Fri May 14 03:41:00 2010
From: report at bugs.python.org (Dan Buch)
Date: Fri, 14 May 2010 01:41:00 +0000
Subject: [issue8698] PEP 391: Adding documentation of logging.config.dictConfig
In-Reply-To: <1273674437.89.0.924445396649.issue8698@psf.upfronthosting.co.za>
Message-ID: <1273801260.82.0.430455758215.issue8698@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8698>
_______________________________________

From report at bugs.python.org  Fri May 14 03:43:38 2010
From: report at bugs.python.org (Dan Buch)
Date: Fri, 14 May 2010 01:43:38 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273801418.93.0.628184866772.issue2142@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Fri May 14 03:44:28 2010
From: report at bugs.python.org (Dan Buch)
Date: Fri, 14 May 2010 01:44:28 +0000
Subject: [issue8704] cgitb sends a bogus HTTP header if the app crashes before
	finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1273801468.65.0.58999212461.issue8704@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8704>
_______________________________________

From report at bugs.python.org  Fri May 14 03:45:31 2010
From: report at bugs.python.org (Dan Buch)
Date: Fri, 14 May 2010 01:45:31 +0000
Subject: [issue8706] accept keyword arguments on all base type methods and
	builtins
In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za>
Message-ID: <1273801531.57.0.869362414931.issue8706@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8706>
_______________________________________

From report at bugs.python.org  Fri May 14 04:17:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 02:17:02 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273787928.79.0.0765796576975.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTinJ1DTSl7IzAClSPmrL_QQMT7k3G8JdroYnAZtr@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, May 13, 2010 at 5:58 PM, Mark Dickinson <report at bugs.python.org> wrote:
>??Optimizations that speed up, say, factorial(n) for n <= 1000 would seem more valuable.

I am attaching a variant of my patch which precomputes partial
products that fit in 32 bit unsigned int.  This results in speed up
over Daniel's code which varies from 1.8x for 20! down to 7% for 100!
and no measurable improvement for 1000!.

This optimization is orthogonal to the choice of partial_product
algorithm and can be easily extended on platforms with long long to
precompute 64 bit products.

----------
Added file: http://bugs.python.org/file17325/factorial-precompute-partials.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
Index: Modules/mathmodule.c
===================================================================
--- Modules/mathmodule.c	(revision 81150)
+++ Modules/mathmodule.c	(working copy)
@@ -1129,56 +1129,183 @@
 Return an accurate floating point sum of values in the iterable.\n\
 Assumes IEEE-754 floating point arithmetic.");
 
+/* Divide-and-conquer factorial algorithm
+ *
+ * Based on the formula and psuedo-code provided at:
+ * http://www.luschny.de/math/factorial/binarysplitfact.html
+ *
+ * Faster algorithms exist, but they're more complicated and depend on
+ * a fast prime factoriazation algorithm.
+ */
+
+static unsigned long 
+precomputed[] = {3, 15, 5, 35, 315, 63, 693, 9009, 1287, 19305, 328185, 36465, 692835,
+		 14549535, 1322685, 30421755, 760543875, 58503375, 1579591125ul, 3053876175ul};
+/* i-th odd number */
+#define ODD(i) (((i) << 1) | 1) 
+/* Compute product(ODD(i) for i in range(first, last+1)) */
 static PyObject *
+factorial_partial_product(unsigned long first, unsigned long last)
+{
+    PyObject *result;
+    PyObject *a, *x, *y;
+    Py_ssize_t n, i;
+    
+    if (last < sizeof(precomputed)/sizeof(*precomputed)) {
+	size_t index = first + last - 2;
+	if (index <  sizeof(precomputed)/sizeof(*precomputed)) {
+	    return PyLong_FromUnsignedLong(precomputed[index]);
+	}
+    }
+   
+    n = last - first + 1;
+    if (n <= 0)
+	return PyLong_FromLong(1L);
+    if (n == 1)
+	return PyLong_FromUnsignedLong(ODD(first));
+
+    /* a = [ODD(i) for i in range(first, last + 1)] */
+    a = PyList_New(last - first + 1);
+    if (a == NULL)
+	return NULL;
+    for  (i = 0; i < n; ++i) {
+	result = PyLong_FromUnsignedLong(ODD(first + i));
+	if (result == NULL)
+	    goto done;
+	PyList_SET_ITEM(a, i, result);
+    }
+    while (n > 1) {
+	for (i = (n >> 1) - 1; i >= 0; --i) {
+	    x = PyList_GET_ITEM(a, i);
+	    y = PyList_GET_ITEM(a, n - i - 1);
+	    result = PyNumber_Multiply(x, y);
+	    if (result == NULL)
+		goto done;
+	    PyList_SET_ITEM(a, i, result);
+	    PyList_SET_ITEM(a, n - i - 1, NULL);
+	    Py_DECREF(x);
+	    Py_DECREF(y);
+	}
+	n = (n >> 1) + (n & 1);
+    }
+    /* Release reference held by the list */
+    PyList_SET_ITEM(a, 0, NULL);
+ done:
+    Py_DECREF(a);
+    return result;
+}
+
+static unsigned long
+bit_length(unsigned long n)
+{
+    unsigned long len = 0;
+    while (n != 0) {
+	++len;
+	n >>= 1;
+    }
+    return len;
+}
+
+static unsigned long
+bit_count(unsigned long n)
+{
+    unsigned long count = 0;
+    while (n != 0) {
+	++count;
+	n &= n - 1; /* clear least significant bit */
+    }
+    return count;
+}
+
+static PyObject *
+factorial_loop(unsigned long n)
+{
+    long i, v;
+    PyObject *p, *r;
+    PyObject *part, *tmp;
+
+    p = PyLong_FromLong(1L);
+    if (p == NULL)
+        return NULL;
+    Py_INCREF(p);
+    r = p;
+
+    for (i = bit_length(n) - 2; i >= 0; --i) {
+        v = n >> i;
+        if (v > 2) {
+	    part = factorial_partial_product(((v >> 1) + 1) >> 1, (v - 1) >> 1);
+	    if (part == NULL)
+		goto error;
+
+	    tmp = PyNumber_Multiply(p, part);
+	    Py_DECREF(part);
+	    if (tmp == NULL)
+		goto error;
+	    Py_DECREF(p);
+	    p = tmp;
+
+	    tmp = PyNumber_Multiply(r, p);
+	    if (tmp == NULL)
+		goto error;
+	    Py_DECREF(r);
+	    r = tmp;
+	}
+    }
+    Py_DECREF(p);
+    return r;
+ error:
+    Py_DECREF(p);
+    Py_DECREF(r);
+    return NULL;
+}
+
+static PyObject *
 math_factorial(PyObject *self, PyObject *arg)
 {
-    long i, x;
-    PyObject *result, *iobj, *newresult;
+    PyObject *result;
 
+    PyObject *r; /* result without trailing zeros */
+    PyObject *ntz; /* number of trailing zeros */
+    long n;
+
     if (PyFloat_Check(arg)) {
-        PyObject *lx;
         double dx = PyFloat_AS_DOUBLE((PyFloatObject *)arg);
         if (!(Py_IS_FINITE(dx) && dx == floor(dx))) {
             PyErr_SetString(PyExc_ValueError,
                 "factorial() only accepts integral values");
             return NULL;
         }
-        lx = PyLong_FromDouble(dx);
-        if (lx == NULL)
+        n = (long) dx;
+    } else {
+        n = PyLong_AsLong(arg);
+        if (n == -1 && PyErr_Occurred())
             return NULL;
-        x = PyLong_AsLong(lx);
-        Py_DECREF(lx);
     }
-    else
-        x = PyLong_AsLong(arg);
 
-    if (x == -1 && PyErr_Occurred())
-        return NULL;
-    if (x < 0) {
+    if (n < 0) {
         PyErr_SetString(PyExc_ValueError,
-            "factorial() not defined for negative values");
+                        "factorial() not defined for negative values");
         return NULL;
     }
 
-    result = (PyObject *)PyLong_FromLong(1);
-    if (result == NULL)
+    if (n <= 12) {
+        static const long lookup[] = {1, 1, 2, 6, 24, 120, 720, 5040, 40320,
+                                      362880, 3628800, 39916800, 479001600};
+        return PyLong_FromLong(lookup[n]);
+    }
+
+    r = factorial_loop(n);
+    if (r == NULL)
         return NULL;
-    for (i=1 ; i<=x ; i++) {
-        iobj = (PyObject *)PyLong_FromLong(i);
-        if (iobj == NULL)
-            goto error;
-        newresult = PyNumber_Multiply(result, iobj);
-        Py_DECREF(iobj);
-        if (newresult == NULL)
-            goto error;
-        Py_DECREF(result);
-        result = newresult;
+
+    ntz = PyLong_FromLong(n - bit_count(n));
+    if (ntz != NULL) {
+	result = PyNumber_Lshift(r, ntz);
+	Py_DECREF(ntz);
     }
+
+    Py_DECREF(r);
     return result;
-
-error:
-    Py_DECREF(result);
-    return NULL;
 }
 
 PyDoc_STRVAR(math_factorial_doc,

From report at bugs.python.org  Fri May 14 05:02:40 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 03:02:40 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTinJ1DTSl7IzAClSPmrL_QQMT7k3G8JdroYnAZtr@mail.gmail.com>
Message-ID: <o2neae285401005132002o2fab3a21p82c4e9d42e07e9df@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

That's a clever idea.  Do you have a Python script that generates the
precomputed values?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 05:12:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 03:12:22 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTinJ1DTSl7IzAClSPmrL_QQMT7k3G8JdroYnAZtr@mail.gmail.com>
Message-ID: <s2teae285401005132012x12e6eb7dx866deafb7c4b5963@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

It's a little too clever though.  It gives the wrong answer for 29!.

I'll have a revised version of my patch done sometime tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 05:54:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 03:54:44 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273809284.57.0.92236326713.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Oh, my!

How did that last term get into precomputed list?!

It should have been 

precomputed[] = {3, 15, 5, 35, 315, 63, 693, 9009, 1287, 19305, 328185, 36465, 692835,
                 14549535, 1322685, 30421755, 760543875, 58503375, 1579591125ul};

The next term is 36 bit
>>> product(i<<1|1 for i in range(7,15))
45808142625
>>> _.bit_length()
36

I'll replace the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 05:56:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 03:56:00 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273809360.08.0.161650749664.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a patch to improve the unit tests for the factorial function.

To compute the check value, it keeps a running total instead of recomputing the factorial from scratch inside the loop.  It checks up to range(999) and is quite fast.  The previous code checked range(10).

It also adds the following checks:
 * 0! == 1
 * (sys.maxsize+1)! => OverflowError
 * 10e100 => OverflowError

----------
Added file: http://bugs.python.org/file17326/factorial-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:04:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 04:04:36 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273809876.47.0.122664864528.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17327/factorial-precompute-partials.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:04:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 04:04:45 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273809885.73.0.284948081223.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17327/factorial-precompute-partials.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:04:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 04:04:50 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273809890.24.0.400657587135.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17325/factorial-precompute-partials.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:05:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 04:05:01 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273809901.76.0.745873719756.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17328/factorial-precompute-partials.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:19:04 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 04:19:04 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273810744.57.0.146390012349.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is a simple bash script to run math.factorial(n) through timeit for several values of n.  It makes comparing the speed of different builds MUCH easier.

----------
Added file: http://bugs.python.org/file17329/factorial-speed.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:42:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 04:42:53 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273812173.74.0.923196586574.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark> Does anyone feel like doing a speed comparison between Daniel's C patch and a version with a direct no-frills iterative version of factorial_part_product (i.e., just a simple  'for (i = n; i <= m; i += 2) { <multiply running product by i> }?

Not a direct answer to your question, but replacing a bisect with a no-frills algorithm in my precompute patch gives the following timings:

   n    bisect   no-frills
   100  38.9 us  38.5 us
  1000  .904 ms  1.08 ms
 10000  35.4 ms  50.3 ms


The no-frills product still takes 20 lines of C code though:

    n = last - first + 1;
    if (n <= 0)
        return PyLong_FromLong(1L);

    result = PyLong_FromUnsignedLong(ODD(first));
    if (result == NULL)
        return NULL;
    for  (i = 1; i < n; ++i) {
        x = PyLong_FromUnsignedLong(ODD(first + i));
        if (x == NULL)
            goto error;
        tmp = PyNumber_Multiply(result, x);
        Py_DECREF(x);
        if (tmp == NULL)
            goto error;
        Py_DECREF(result);
        result = tmp;
    }
    return result;
 error:
    Py_DECREF(result);
    return NULL;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 06:59:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 May 2010 04:59:29 +0000
Subject: [issue4898] {context,
	unified}_diff add spurious trailing whitespace if
	fromfiledate/tofiledate are emptyk
In-Reply-To: <1231515492.91.0.948855864536.issue4898@psf.upfronthosting.co.za>
Message-ID: <1273813169.1.0.178982707844.issue4898@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> difflib should separate filename from timestamp with tab

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4898>
_______________________________________

From report at bugs.python.org  Fri May 14 06:59:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 14 May 2010 04:59:59 +0000
Subject: [issue8708] OpenID blunder
In-Reply-To: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>
Message-ID: <1273813199.58.0.320055507305.issue8708@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have retired the user Jack.Diederich.

In the future, please use the meta tracker to discuss issues with this tracker.

----------
nosy: +loewis -Jack.Diederich

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8708>
_______________________________________

From report at bugs.python.org  Fri May 14 07:01:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 May 2010 05:01:02 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273813262.59.0.0553150178042.issue8705@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Fri May 14 08:40:58 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 14 May 2010 06:40:58 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273819258.14.0.82800449513.issue8705@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Tested on Debian 5, also not occurs.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Fri May 14 09:19:02 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 14 May 2010 07:19:02 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1273821542.51.0.29646476013.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file17195/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri May 14 09:19:40 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 14 May 2010 07:19:40 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1273821580.68.0.0999734415821.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Duck, here comes another update to bfs.patch.

This one with some cleanups which simplify the code and improve behavior (on Windows XP), shutdown code, comments, and "experimental" use of TSC for timestamps, which eliminates timestamp reading overhead.

TSC (http://en.wikipedia.org/wiki/Time_Stamp_Counter) is a fast way to get high precision timing read. On some systems this is what gettimeofday() uses under the hood while on other systems it will use HPET or another source which is slower, typically ~1usec, but can be higher (e.g. my core 2 duo laptop occasionally goes into a few hours of charging 3usec per HPET gettimeofday() call - god knows why)

This overhead is incurred twice for every GIL release/acquire pair and can be eliminated with:
1) Hack the scheduler not to call gettimeofday() when no other threads are waiting to run, or
2) Use TSC on platforms it is available (the Linux BFS scheduler uses TSC).

I took cycle.h pointed by the Wikipedia article on TSC for a spin and it works well on my boxes. It is BSD, (un)maintained? and includes implementation for a gazillion of platforms (I did not yet modify configure.in as it recommends). 

If it breaks on your system please ping with details.

Some benchmarks running (Florent's) writes.py on Core 2 Quad q9400 Ubuntu 64bit:

bfs.patch - 35K context switches per second, threads balanced, runtime is 3 times that of running IO thread alone:

~/dev/python$ ~/build/python/bfs/python writes.py
t1 1.60293507576 1
t2 1.78533816338 1
t1 2.88939499855 2
t2 3.19518113136 2
t1 4.38062310219 3
t2 4.70725703239 3
t1 6.26874804497 4
t2 6.4078810215 4
t1 7.83273100853 5
t2 7.92976212502 5
t1 9.4341750145 6
t2 9.57891893387 6
t1 11.077393055 7
t2 11.164755106 7
t2 12.8495900631 8
t1 12.8979620934 8
t1 14.577999115 9
t2 14.5791089535 9
t1 15.9246580601 10
t2 16.1618289948 10
t1 17.365830183 11
t2 17.7345991135 11
t1 18.9782481194 12
t2 19.2790091038 12
t1 20.4994370937 13
t2 20.5710251331 13
21.0179870129


dabeaz_gil.patch - sometimes runs well but sometimes goes into high level of context switches (250K/s) and produces output such as this:

~/dev/python$ ~/build/python/dabeaz/python writes.py 
t1 0.742760896683 1
t1 7.50052189827 2
t2 8.63794493675 1
t1 10.1924870014 3
17.9419858456

gilinter2.patch - 300K context switches per second, bg threads starved:

~/dev/python$ ~/build/python/gilinter/python writes.py 
t2 6.1153190136 1
t2 11.7834780216 2
14.5995650291

----------
Added file: http://bugs.python.org/file17330/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Fri May 14 09:43:15 2010
From: report at bugs.python.org (akira)
Date: Fri, 14 May 2010 07:43:15 +0000
Subject: [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

Currently it is not obvious that os.devnull works on Windows.

----------
assignee: docs at python
components: Documentation
files: doc-os-devnull-windows-r81160.diff
keywords: patch
messages: 105688
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: mention explicitly Windows support for os.devnull
type: feature request
Added file: http://bugs.python.org/file17331/doc-os-devnull-windows-r81160.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8709>
_______________________________________

From report at bugs.python.org  Fri May 14 09:46:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 07:46:02 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273788547.25.0.612184566517.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTikqeBfLCNyeMvh4CAGb-t8Qz5lXp-wWRRReb3iS@mail.gmail.com>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
>
> Speaking of getting side-tracked, I didn't see an answer to a question I asked earlier. ?I'd like to get some feedback before I proceed with revising the patch.
>
> For the find-last-set-bit (to replace log2) and count-set-bits operations, would it be worthwhile to create a pybits.h and .c that defines _Py_FindLastSetBit and _Py_CountSetBits? (with appropriate logic in the .h and configure.in to use system/compiler versions if available)

How about putting them in pymath.c and pymath.h?   Then there's no
need for new files.  There's the possible issue that the two
bit-counting methods operate on different types, though.

> There are already two implementations of find-last-set-bit in Python:
> bits_in_digit() in Objects/longobject.c and hi0bits() in Python/dtoa.c, which I could consolidate.

dtoa.c should be left alone, ideally:  it's currently almost
completely self-contained, and also very close to the original dtoa.c
from David Gay, which makes it easy to incorporate fixes from
upstream.  So it's just Objects/longobject.c that would share the
code.

> Alternately, I could just add static functions to mathmodule.c with the simplest possible implementation (they're only called once per factorial, so the performance impact is minimal).

That would work, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 09:57:49 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 14 May 2010 07:57:49 +0000
Subject: [issue8704] cgitb sends a bogus HTTP header if the app crashes before
	finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1273823869.92.0.595675465583.issue8704@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Yes, I saw the "<!--: spam" string in headers, but it seems that this string doesn't make problems. The displaying page is correct.


But after I apply the changes you mentioned:
-    return '''<!--: spam
+    return '''\r\n\r\n<!--: spam


I got text/plain output, and the response headers are like this:

    Date	Fri, 14 May 2010 07:30:03 GMT
    Server	Apache/2.2.15 (Unix)
    Keep-Alive	timeout=5, max=100
    Connection	Keep-Alive
    Transfer-Encoding	chunked
    Content-Type	text/plain



And the content is like this:

<!--: spam
Content-Type: text/html

<body bgcolor="#f0f0f8"><font color="#f0f0f8" size="-5"> -->
<body bgcolor="#f0f0f8"><font color="#f0f0f8" size="-5"> --> -->

......



So the hole page is not displayed correctly!

Is there any problem with me?

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8704>
_______________________________________

From report at bugs.python.org  Fri May 14 10:04:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 08:04:56 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273824296.82.0.443876784381.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I am attaching an iterative version in C patch.

Thanks for doing this comparison.

> The performance  appears to be identical to Daniel's with no small
> integer multiplication optimization.

Okay, let's stick with the recursive version, then.  It has the advantage that it uses less space (no need to store the entire list of odd terms).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 10:54:21 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 14 May 2010 08:54:21 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273827261.05.0.206723948456.issue2142@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

This is really a bug, but why it's not fixed during such a long time?

Since trentm's python_difflib_no_eol.patch patch failed against the current trunk, I modified it to work again, also a patch against py3k.

----------
nosy: +ysj.ray
Added file: http://bugs.python.org/file17332/issue_2142_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Fri May 14 10:54:51 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 14 May 2010 08:54:51 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273827291.63.0.759794276014.issue2142@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Added file: http://bugs.python.org/file17333/issue_2142_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Fri May 14 11:13:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 09:13:57 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273828437.24.0.615410368052.issue2142@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think it's arguable whether this is a bug or not.  There's no official specification for the unified diff format that I can find anywhere;  the GNU description at

http://www.gnu.org/software/hello/manual/diff/Detailed-Unified.html#Detailed-Unified

doesn't mention this detail.  The '\ No newline at end of file' is actually unnecessary for these Python functions, since they operate on lists and produce a generator, so it would be needless complication.  And changing this might break existing Python code that manually parses the output of unified_diff or context_diff and doesn't know what to do with a leading '\' character.  (Does such Python code exist?  I don't know.)

I'd suggest adding a keyword argument to the unified_diff and context_diff  functions to enable this feature, leaving it disabled by default.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Fri May 14 11:19:42 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 09:19:42 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1273828782.17.0.607167347452.issue6419@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The same patch was applied to the Python port by OpenBSD developer Damien Miller:

http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_kqueue_py


Mark, would it be ok in this situation to apply the patch even though
personally I don't know if OpenBSD kqueue behaves like Darwin kqueue?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Fri May 14 12:03:59 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 14 May 2010 10:03:59 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273831439.44.0.230476558438.issue8705@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Fri May 14 12:04:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 14 May 2010 10:04:36 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273831476.66.0.980515520684.issue8705@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Dan,

Can I have the error you get ?

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Fri May 14 12:28:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 10:28:30 +0000
Subject: [issue8640] subprocess: add envb argument to Popen constructor
	(Python3, POSIX only)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273832910.31.0.208646290701.issue8640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why wouldn't you give byte variables in env too?

The problem with the canonicalization to bytes is to choice of the preferred type. Eg. env={'PATH': 'a', b'PATH': b'b'}: should we use 'a', 'b' or raise an error?

subprocess does already convert environ keys and values to bytes on Unix (in subprocess._execute_child() if _posixsubprocess module is present, and in posix_execve()).

os.get_exec_path() should also support b'PATH' key.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Fri May 14 12:29:19 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 10:29:19 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1273832959.9.0.607293337507.issue8424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Luckily, the OpenBSD failures are caused by issues in libpthread. This
means that some skips could be added (as for FreeBSD), but I'll open
a separate issue for that.


Thanks for the comments on the patch. I add two new patches that
incorporate the stderr/SkipTest suggestions.


Should I apply them and close this issue?

----------
Added file: http://bugs.python.org/file17334/issue8424-release26-stderr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Fri May 14 12:29:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 10:29:41 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1273832981.3.0.217397898062.issue8424@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file17335/issue8424-trunk-skiptest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Fri May 14 12:55:57 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 10:55:57 +0000
Subject: [issue8710] test_xpickle: compat tests: workaround for missing
	test_support
In-Reply-To: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>
Message-ID: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

When the system python does not have the Lib/test directory, the
compat tests are failing.


======================================================================
ERROR: test_attribute_name_interning (test.test_xpickle.CPicklePython26Compat)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/svn/trunk/Lib/test/pickletester.py", line 959, in test_attribute_name_interning
    s = self.dumps(x, proto)
  File "/home/stefan/svn/trunk/Lib/test/test_xpickle.py", line 114, in dumps
    return self.send_to_worker(self.python, arg, proto)
  File "/home/stefan/svn/trunk/Lib/test/test_xpickle.py", line 110, in send_to_worker
    raise RuntimeError(stderr)
RuntimeError: Traceback (most recent call last):
  File "/home/stefan/svn/trunk/Lib/test/test_xpickle.py", line 17, in <module>
    from test import test_support
ImportError: No module named test

----------
components: Tests
messages: 105698
nosy: collinwinter, skrah
priority: normal
severity: normal
status: open
title: test_xpickle: compat tests: workaround for missing test_support
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8710>
_______________________________________

From report at bugs.python.org  Fri May 14 13:21:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 14 May 2010 11:21:12 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1273836072.9.0.854375793727.issue8256@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

since the prompt is written to stderr, why is sys.stdout.encoding used instead of sys.stderr.encoding?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Fri May 14 13:31:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 11:31:07 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
	io.StringIO().encoding is None
In-Reply-To: <1273836072.9.0.854375793727.issue8256@psf.upfronthosting.co.za>
Message-ID: <201005141331.00888.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

amaury> since the prompt is written to stderr, why is sys.stdout.encoding
amaury> used instead of sys.stderr.encoding?

input() calls PyOS_Readline() but PyOS_Readline() has multiple 
implementations:
 - PyOS_StdioReadline() if sys_stdin or sys_stdout is not a TTY
 - or PyOS_ReadlineFunctionPointer callback:
   - vms__StdioReadline() (VMS only)
   - PyOS_StdioReadline()
   - call_readline() when readline module is loaded

call_readline() calls rl_callback_handler_install() with the prompt which 
writes the prompt to *stdout* (try ./python 2>/dev/null).

I don't think that it really matters that the prompt is written to stderr with 
stdout encoding, because both outputs always use the same encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8256>
_______________________________________

From report at bugs.python.org  Fri May 14 14:21:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 12:21:00 +0000
Subject: [issue3771] test_httpservers intermittent failure, test_post and EINTR
In-Reply-To: <1220489239.6.0.433848845577.issue3771@psf.upfronthosting.co.za>
Message-ID: <1273839660.62.0.679011940372.issue3771@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The EINTR issue should be fixed in trunk (issue1628205). Have you by
any chance run the test suite on trunk in the meantime?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3771>
_______________________________________

From report at bugs.python.org  Fri May 14 14:26:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 12:26:24 +0000
Subject: [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273839984.6.0.607759371762.issue8709@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If there?s no note stating some object is only available on one platform, then it?s available for all. That said, for this case I agree with your patch.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8709>
_______________________________________

From report at bugs.python.org  Fri May 14 14:27:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 12:27:56 +0000
Subject: [issue8710] test_xpickle: compat tests: workaround for missing
	test_support
In-Reply-To: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>
Message-ID: <1273840076.08.0.824107331905.issue8710@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t understand your installation. Do you have some parts of the test infrastructure but not test_support? Why?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8710>
_______________________________________

From report at bugs.python.org  Fri May 14 14:38:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 May 2010 12:38:50 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1273840730.48.0.489095867713.issue1813@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Fri May 14 14:42:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 12:42:25 +0000
Subject: [issue8710] test_xpickle: compat tests: workaround for missing
	test_support
In-Reply-To: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>
Message-ID: <1273840945.44.0.386192853005.issue8710@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The compat tests check that pickling in the newly compiled Python
version is compatible with pickling in installed Python versions.

The installed versions may or may not have a test directory. For
example, the 2.6 port in OpenBSD does not have the test directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8710>
_______________________________________

From report at bugs.python.org  Fri May 14 15:06:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 13:06:37 +0000
Subject: [issue8704] cgitb sends a bogus HTTP header if the app crashes before
	finishing headers
In-Reply-To: <1273759972.28.0.178671810955.issue8704@psf.upfronthosting.co.za>
Message-ID: <1273842397.39.0.633895982291.issue8704@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

It displays correctly in some browsers, yes, but not everything that speaks HTTP is a browser.  For example, the invalid header makes C#'s WebRequest throw an exception.

I hadn't noticed the 'Content-Type' on the next line of the string output by reset().  That does make things more complicated.

We could put the "Content-Type: text/html" first, but the downside is that it will be output as visible content if a script crashes after the headers have been emitted.

I'm not sure if that's better or worse than emitting an invalid header.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8704>
_______________________________________

From report at bugs.python.org  Fri May 14 15:34:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 13:34:16 +0000
Subject: [issue8711] Document PyUnicode_DecodeFSDefault() and
	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached patch document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() in Doc/c-api/, and fix comment in Include/unicodeobject.c (remove reference to bytearray, and specify that surrogateescape is used).

The patch adds also titles to group unicode functions and methods by topic.

----------
assignee: docs at python
components: Documentation, Unicode
files: unicode_doc.patch
keywords: patch
messages: 105706
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17336/unicode_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8711>
_______________________________________

From report at bugs.python.org  Fri May 14 15:35:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 May 2010 13:35:40 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1273844140.68.0.241098518059.issue6610@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would the test still be correct if it didn't close stderr? I feel closing stderr is very bad from a debuggability standpoint.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________

From report at bugs.python.org  Fri May 14 15:48:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 13:48:41 +0000
Subject: [issue8711] Document
	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <4BED54B4.8030507@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

The bulk of the patch seems good to me, with some minor remarks:
- You haven?t used title case consistently in all section titles.
- I?d just say ?wchar_t Support? in a title, deleting ?for platforms
which support it?.
- You could mark up ?bytes? so that users get a link.
- The verb form of ?fall back? is in two words, unless I?m lagging on
current technical English.
- You lack an article when saying ?the "surrogateescape" error handler?.
- Not sure: Is it better to say ?for encoding x, use y? or ?to encode x,
use y??

Sorry for not giving precise line numbers or a diff of a diff, that
wouldn?t be practical.

----------
nosy: +merwok
title: Document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() -> Document PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8711>
_______________________________________

From report at bugs.python.org  Fri May 14 16:13:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 14:13:58 +0000
Subject: [issue8712] Skip libpthread related test failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

[Added OpenBSD Python port maintainers to the nosy list.]

I've identified a number of tests that all pass when Python is compiled
without threads, but fail otherwise. The failures are probably caused
by libpthread issues in OpenBSD, as described in this patch:


http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_signal_py


Would you agree that it is reasonable to skip all these tests until
libpthread is fixed?

----------
components: Tests
files: openbsd_libpthread_skips.patch
keywords: needs review, patch
messages: 105709
nosy: djmdjm, henry.precheur, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Skip libpthread related test failures on OpenBSD
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17337/openbsd_libpthread_skips.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8712>
_______________________________________

From report at bugs.python.org  Fri May 14 16:28:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 May 2010 14:28:55 +0000
Subject: [issue8424] Test assumptions for test_itimer_virtual and
	test_itimer_prof
In-Reply-To: <1271435798.21.0.520260917353.issue8424@psf.upfronthosting.co.za>
Message-ID: <1273847335.64.0.93593656303.issue8424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patches look good, so yes, please apply them.  As for closing the issue...if the failures are no longer happening on the buildbots, then yes :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8424>
_______________________________________

From report at bugs.python.org  Fri May 14 16:35:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 14:35:07 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273847707.89.0.0398713206512.issue8692@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file17300/factorial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 16:40:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 May 2010 14:40:59 +0000
Subject: [issue8712] Skip libpthread related test failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273848059.08.0.353554114748.issue8712@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks reasonable. Perhaps you should add a reference to the relevant OpenBSD bug number(s) or URL(s), if any.

----------
nosy: +exarkun, mark.dickinson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8712>
_______________________________________

From report at bugs.python.org  Fri May 14 16:45:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 May 2010 14:45:46 +0000
Subject: [issue8711] Document
	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273848346.92.0.661096130405.issue8711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is it better to say ?for encoding x, use y? or ?to encode x,
> use y??

The latter, IMO. "Encoding" is also a noun.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8711>
_______________________________________

From report at bugs.python.org  Fri May 14 16:46:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 14:46:09 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1273848369.28.0.346178051072.issue6419@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, please do apply the patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Fri May 14 16:55:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 14:55:52 +0000
Subject: [issue8711]
	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273848346.92.0.661096130405.issue8711@psf.upfronthosting.co.za>
Message-ID: <4BED6475.20204@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

In this case, it was a verb (a gerund form).

----------
title: Document PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize() -> Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8711>
_______________________________________

From report at bugs.python.org  Fri May 14 16:58:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 14:58:05 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273849085.86.0.611735138111.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Attached is an updated patch.

In addition to the code cleanup and bug fix suggestions, it includes a new base-case for factorial_partial_product.  Instead of:

if (n >= m)
    return n
if (n + 2 == m)
    return n*m
otherwise divide-and-conquer

It now does:

if (the_answer_will_fit_in_unsigned_long)
    compute_product_via_tight_loop()
    return answer
otherwise divide-and-conquer

It's around half the code of the previous factorial_partial_product(), if you don't count comments.  It's also much faster for small n and somewhat faster for moderate n.

original patch:
13: 0.848 usec
50: 2.4 usec
100: 4.68 usec
1000: 121 usec
10000: 7.68 msec
100000: 434 msec

new patch:
13: 0.5 usec
50: 1.2 usec
100: 2.28 usec
1000: 100 usec
10000: 7.32 msec
100000: 447 msec

I also experimented with adding Alexander's precompute logic to my factorial_loop.  However, it did not result in a significant speedup, since all of the cases that could leverage the precompute table now execute in the new fast base case.

The new patch includes the new unit tests I uploaded earlier.

----------
Added file: http://bugs.python.org/file17338/factorial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 16:58:47 2010
From: report at bugs.python.org (Dan Koch)
Date: Fri, 14 May 2010 14:58:47 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1273849127.66.0.978958014101.issue8705@psf.upfronthosting.co.za>


Dan Koch <kochdb at ornl.gov> added the comment:

Here's the session printout. Desktop files under Vista still get deleted despite the exception. Does not occur on Fedora 12 or Mac OS X. I can code around it by testing for a blank filepath, but it was a surprise.

C:\Users\ko5>python
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, shutil, user
>>> desktop_dir = os.path.join(user.home, 'Desktop')
>>> os.chdir(desktop_dir)
>>> os.getcwd()
'C:\\Users\\ko5\\Desktop'
>>> shutil.rmtree('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python26\lib\shutil.py", line 225, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\Python26\lib\shutil.py", line 223, in rmtree
    os.rmdir(path)
WindowsError: [Error 3] The system cannot find the path specified: ''
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Fri May 14 17:08:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 15:08:00 +0000
Subject: [issue8711]
	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273849680.47.0.297308054054.issue8711@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks for your remarks: updated patch.

----------
Added file: http://bugs.python.org/file17339/unicode_doc-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8711>
_______________________________________

From report at bugs.python.org  Fri May 14 18:09:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:09:08 +0000
Subject: [issue8711]
	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273853348.22.0.55510763748.issue8711@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r81168 (py3k), r81169 (3.1).

I also added the paragraph titles to Python2: r81166 (trunk) and r81167 (2.6).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8711>
_______________________________________

From report at bugs.python.org  Fri May 14 18:13:11 2010
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Fri, 14 May 2010 16:13:11 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

The "multiprocessing" module uses a bare fork() to create child processes under Linux, so the children get a copy of the entire state of the parent process.  But under Windows, child processes are freshly spun-up Python interpreters with none of the data structures or open connections of the parent process available.  This means that code that tests fine under Linux, because it is depending on residual parent state in a way that the programmer has not noticed, can fail spectacularly under Windows.

Therefore, the "multiprocessing" module should offer an option under Linux that ignores the advantage of being able to do a bare fork() and instead spins up a new interpreter instance just like Windows does.  Some developers will just use this for testing under Linux, so their test results are valid for Windows too; and some developers might even use this in production, preferring to give up a bit of efficiency under Linux in return for an application that will show the same behavior on both platforms.  Either way, an option that lets the developer subvert the simple "sys.platform != 'win32'" check in "forking.py" would go a long way towards helping us write platform-agnostic Python programs.

----------
components: Library (Lib)
messages: 105719
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: multiprocessing needs option to eschew fork() under Linux
type: feature request
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/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 14 18:26:04 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 16:26:04 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On OpenBSD, SIGINT handling in the REPL is delayed until further input:

Python 2.7b2+ (trunk:81162, May 14 2010, 14:47:52) 
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>>  <= here Ctrl-C is pressed but nothing appears
Only after hitting <Return> a traceback appears:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt


This behavior was introduced (exposed by?) r68460.


When Python is compiled without threads, the behavior is normal.

----------
components: Interpreter Core
messages: 105720
nosy: djmdjm, henry.precheur, skrah
priority: normal
severity: normal
status: open
title: Delayed signals in the REPL on OpenBSD (possibly libpthread related)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Fri May 14 18:53:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:53:55 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_EncodeFSDefault() is the opposite of PyUnicode_DecodeFSDefault(AndSize)() and is similar to the new function os.fsencode(). As you can see in the patch, it simplifies many functions.

/* Encodes a Unicode object to Py_FileSystemDefaultEncoding with the
   "surrogateescape" error handler and returns a bytes object.

   If Py_FileSystemDefaultEncoding is not set, fall back to UTF-8.
*/

PyAPI_FUNC(PyObject*) PyUnicode_EncodeFSDefault(
    PyObject *unicode
    );

The function unify the behaviour when Py_FileSystemDefaultEncoding is NULL: use UTF-8 whereas import uses ASCII. Other functions did already fall back to UTF-8: PyUnicode_AsEncodedString() uses PyUnicode_GetDefaultEncoding() (hardcoded to utf8 in Python3) if encoding is NULL

The patch does also fix tkinter module initializer (use surrogateescape error handler, instead of strict).

The patch was first attached to issue #8611.

----------
components: Interpreter Core, Unicode
files: pyunicode_encodefsdefault-2.patch
keywords: patch
messages: 105721
nosy: Arfrever, benjamin.peterson, ezio.melotti, gregory.p.smith, haypo, lemburg, loewis, pitrou
priority: normal
severity: normal
status: open
title: Create PyUnicode_EncodeFSDefault() function
versions: Python 3.2
Added file: http://bugs.python.org/file17340/pyunicode_encodefsdefault-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Fri May 14 18:56:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:56:35 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273856195.7.0.894000133164.issue8715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, I attached the wrong version of the patch. Version 3 changes the documentation (Encodes => Encode).

----------
Added file: http://bugs.python.org/file17341/pyunicode_encodefsdefault-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Fri May 14 18:56:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:56:39 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273856199.22.0.350032297658.issue8715@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17340/pyunicode_encodefsdefault-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Fri May 14 18:56:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:56:54 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1273856214.11.0.0889620859525.issue8611@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17251/pyunicode_encodefsdefault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Fri May 14 18:57:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:57:25 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1273856245.56.0.895212340343.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened a separated issue for the new function PyUnicode_EncodeFSDefault(): #8715.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Fri May 14 19:01:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 May 2010 17:01:17 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273856477.6.0.893133427852.issue8713@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 14 19:15:29 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 14 May 2010 17:15:29 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273857329.57.0.294917166456.issue8713@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

This is on my wish list; but I have not had time to do it. Patch welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 14 19:39:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 17:39:06 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1273858746.25.0.0182922848873.issue5099@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python3 compilation fails on Windows:
....
  File "...\3.x.bolen-windows\build\lib\subprocess.py", line 911, in Popen
    _WaitForSingleObject=WaitForSingleObject,
NameError: name 'WaitForSingleObject' is not defined

http://www.python.org/dev/buildbot/3.x.stable/builders/x86%20XP-4%203.x/builds/2121/steps/compile/logs/stdio

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Fri May 14 19:45:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 17:45:48 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273859148.76.0.421317865999.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17310/factorial.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 19:45:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 17:45:53 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273859153.27.0.698158621179.issue8692@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file17312/factorial3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 19:49:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 17:49:16 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273859356.48.0.866543796278.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch: use sys.stdout.encoding instead of ASCII. (If stdout is not a TTY, sys.stdout.encoding is ASCII.)

----------
Added file: http://bugs.python.org/file17342/distutils_spawn_log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Fri May 14 19:49:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 17:49:20 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273859360.01.0.377967747368.issue8663@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17268/distutils_spawn_toascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Fri May 14 19:54:09 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 14 May 2010 17:54:09 +0000
Subject: [issue8712] Skip libpthread related test failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273859649.43.0.26853742793.issue8712@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

In addition to skipping the tests, would it also make sense to document these known limitations of Python threading on OpenBSD somewhere that end users might see it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8712>
_______________________________________

From report at bugs.python.org  Fri May 14 19:58:10 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 14 May 2010 17:58:10 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1273859890.02.0.278198724861.issue6419@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, thanks. - The patch is good on OpenBSD-4.5-i386-Celeron,
but I get additional failures on OpenBSD-4.7-beta-amd64-QEMU.

This could be the result of running a beta under qemu.

Henry, could you confirm if the patch works on amd64/OpenBSD-4.7-stable?



======================================================================
FAIL: test_create_event (test.test_kqueue.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/svn/py3k/Lib/test/test_kqueue.py", line 29, in test_create_event
    self.assertEqual(ev.ident, fd)
AssertionError: 562945658454018 != 2

======================================================================
FAIL: test_queue_event (test.test_kqueue.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/svn/py3k/Lib/test/test_kqueue.py", line 130, in test_queue_event
    (server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(1688841270329350, -2, 5), (1... != [(6, -2, 0), (7, -2, 0)]

First differing element 0:
(1688841270329350, -2, 5)
(6, -2, 0)

- [(1688841270329350, -2, 5), (1688841270329351, -2, 5)]
+ [(6, -2, 0), (7, -2, 0)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Fri May 14 20:05:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 18:05:07 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273860307.82.0.964072110155.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree, recursive version of partial_product is much simpler to follow.  While allocation of all numbers can be avoided in iterative version, doing so would further complicate code with little benefit.

I still believe, however that an iterative version can benefit from redefining partial_product to be product(2*i+1 for i in range(start, stop)).

Divide and conquer algorithm for that is simply

def partial_product(start, stop):
    length = stop - start
    .. handle length = 1 and 2 ..
    middle = start + (length >> 1)
    return partial_product(start, middle) * partial_product(middle, stop)

I would also reconsider the decision of using iterative outer loop.  Recursive outer loop matching redefined partial_product() can be written as

def loop(n):
    p = r = 1
    if n > 2:
        p, r = loop(n >> 1)
        p *= partial_product((n >> 2) + (n >> 1 & 1),
                             (n >> 1) + (n & 1))
        r *= p
    return p, r

which I believe is not harder to follow than the iterative alternative and does not require bit_length calculation.

I am replacing my python implementation, factorial.py, with the one that uses algorithms outlined above.

If there is any interest, I can convert it to C.

----------
Added file: http://bugs.python.org/file17343/factorial.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 20:05:48 2010
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Fri, 14 May 2010 18:05:48 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273860348.41.0.566570019479.issue8713@psf.upfronthosting.co.za>


Brandon Craig Rhodes <brandon at rhodesmill.org> added the comment:

Jesse, it's great to learn it's on your wish list too!

Should I design the patch so that (a) there is some global in the module that needs tweaking to choose the child creation technique, or (b) that an argument to the Process() constructor forces a full interpreter exec to make all platforms match, or (c) that a process object once created has an attribute (like ".daemon") that you set before starting it off?  Or (d) should there be a subclass of Process that, if specifically used, has the fork/exec behavior instead of just doing the fork?

My vote would probably be for (b), but you have a much better feel for the library and its style than I do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 14 20:06:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 May 2010 18:06:42 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273860402.39.0.430338643385.issue8692@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I still believe, however that an iterative version can benefit ..

s/iterative/recursive/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 20:11:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 18:11:13 +0000
Subject: [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273860673.21.0.8043945279.issue8649@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If, for this and your previous two issues, you could add a suggestion as to precisely where you would make an addition and what minimally adequate text you would add (even unformatted ascii text in a message) that is consistent with surrounding style, action would likely happen sooner.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8649>
_______________________________________

From report at bugs.python.org  Fri May 14 20:21:52 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 14 May 2010 18:21:52 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

test_tk fails on OS X if test is run from a daemon process without the privilege to access the window server, say a buildbot slave without anyone logged in to the console.  The Tk support needs to check whether it has access rights to the window server before trying to access it.

Workaround is to log buildbot into the console of the OS X machine (which usually but not always works), or to run tests manually.

----------
components: Tests, Tkinter
messages: 105733
nosy: janssen
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
type: crash
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/issue8716>
_______________________________________

From report at bugs.python.org  Fri May 14 20:27:43 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 14 May 2010 18:27:43 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273861663.86.0.582870181155.issue8713@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I pretty much agree with (b) an argument - your gut instinct is correct - there's a long standing thread in python-dev which pretty much solidified my thinking about whether or not we need this (we do). 

Any patch has to be backwards compatible by the way, it can not alter the current default behavior, also, it has to target python3 as 2.7 is nearing final, and this is a behavioral change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 14 20:29:08 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 14 May 2010 18:29:08 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1273861748.27.0.106311844146.issue8716@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

[More info from Ronald Oussoren]

This is a bug in Tk: 

>>> root = Tkinter.Tk()
Thu May 13 20:45:13 Rivendell.local python[84887] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
>>> 2010-05-13 20:45:16.751 Python[84887:d07] An uncaught exception was raised
2010-05-13 20:45:16.762 Python[84887:d07] Error (1002) creating CGSWindow
2010-05-13 20:45:16.955 Python[84887:d07] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x00007fff85e31d24 __exceptionPreprocess + 180
	1   libobjc.A.dylib                     0x00007fff860000f3 objc_exception_throw + 45
	2   CoreFoundation                      0x00007fff85e31b47 +[NSException raise:format:arguments:] + 103
	3   CoreFoundation                      0x00007fff85e31ad4 +[NSException raise:format:] + 148
	4   AppKit                              0x00007fff84614aba _NSCreateWindowWithOpaqueShape2 + 473
	5   AppKit                              0x00007fff845a9055 -[NSWindow _commonAwake] + 1214
	6   AppKit                              0x00007fff845c6d3d -[NSWindow _makeKeyRegardlessOfVisibility] + 96
	7   AppKit                              0x00007fff845c6cb2 -[NSWindow makeKeyAndOrderFront:] + 24
	8   Tk                                  0x000000010075b86c XMapWindow + 155
	9   Tk                                  0x00000001006ca6d0 Tk_MapWindow + 89
	10  Tk                                  0x00000001006d35e6 TkToplevelWindowForCommand + 2658
	11  Tcl                                 0x00000001006300d3 TclServiceIdle + 76
	12  Tcl                                 0x00000001006162ce Tcl_DoOneEvent + 329
	13  _tkinter.so                         0x0000000100595683 Tkapp_CallDeallocArgs + 277
	14  readline.so                         0x00000001001f1f9a initreadline + 1280
	15  Python                              0x00000001000076a1 PyOS_Readline + 239
	16  Python                              0x0000000100008a57 PyTokenizer_FromString + 1322
	17  Python                              0x00000001000090a0 PyTokenizer_Get + 154
	18  Python                              0x0000000100005698 PyParser_AddToken + 1018
	19  Python                              0x00000001000a2320 PyParser_ASTFromFile + 146
	20  Python                              0x00000001000a443f PyRun_InteractiveOneFlags + 345
	21  Python                              0x00000001000a4615 PyRun_InteractiveLoopFlags + 206
	22  Python                              0x00000001000a4685 PyRun_AnyFileExFlags + 76
	23  Python                              0x00000001000b0286 Py_Main + 2718
	24  Python                              0x0000000100000e6c start + 52
	25  ???                                 0x0000000000000001 0x0 + 1
)
terminate called after throwing an instance of 'NSException'
Abort trap


This is running /usr/bin/python in a session as a user that doesn't have access to the GUI.  The text above says that there is an uncaught ObjC exception, caused by the lack of a connection to the window server. Tk should have converted that to its own style of errors but didn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Fri May 14 20:34:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 14 May 2010 18:34:36 +0000
Subject: [issue8717] Subprocess.py broken in trunk
In-Reply-To: <1273862076.01.0.24732603883.issue8717@psf.upfronthosting.co.za>
Message-ID: <1273862076.01.0.24732603883.issue8717@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

There seems to have been some broken commit on subprocess.py in trunk - the moduel can't be imported due to unexisting argument defaults.

Here is a very quick patch, but more inquiry migh tbe necessary to find out what happened.

----------
files: broken_subprocess.patch
keywords: patch
messages: 105736
nosy: pakal
priority: normal
severity: normal
status: open
title: Subprocess.py broken in trunk
versions: Python 2.7
Added file: http://bugs.python.org/file17344/broken_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8717>
_______________________________________

From report at bugs.python.org  Fri May 14 20:36:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 18:36:42 +0000
Subject: [issue8717] Subprocess.py broken in trunk
In-Reply-To: <1273862076.01.0.24732603883.issue8717@psf.upfronthosting.co.za>
Message-ID: <1273862202.16.0.706244607634.issue8717@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The regression was introduced by r81154: issue #5099.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8717>
_______________________________________

From report at bugs.python.org  Fri May 14 20:37:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 18:37:16 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1273862236.47.0.285206607823.issue5099@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pakal wrote a patch fixing Windows regression: see issue #8717.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Fri May 14 20:51:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 18:51:11 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273863071.27.0.96769394198.issue8677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Mark just fixed audioop in #8675

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Fri May 14 20:55:56 2010
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 14 May 2010 18:55:56 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1273863356.9.0.627599205887.issue8716@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

It's fairly easy to create a restricted process tree for testing.  ssh into a Mac which has no one logged into the console, from another machine, and use that connection to launch an xterm or Xemacs window to the other machine.  Then log out of the ssh session.  The session running in the xterm will now have no access privileges to the window server, and can be used for testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Fri May 14 20:58:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 18:58:25 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273863505.14.0.410933087169.issue8677@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And the curses module was made PY_SSIZE_T_CLEAN in r81085 (a very simple change).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Fri May 14 21:11:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:11:01 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273864261.18.0.236753697541.issue8686@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Tim. Drop the zero-info glosses. For real_quick_ratio(),
    "Return an upper bound on ratio() even more quickly."
should be sufficient (assuming that it *is* always quicker.

Just curious, The descriptions say ratio() <= quick_ratio() and ratio() <= very_quick_ratio. is it also guaranteed that quick_ratio() <= real_quick_ratio()? Or might one 'luck out' with a better answer from the faster method? (I can imagine either being true.)

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Fri May 14 21:17:10 2010
From: report at bugs.python.org (Tim Peters)
Date: Fri, 14 May 2010 19:17:10 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273864630.36.0.95117924796.issue8686@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Terry asks:

> is it also guaranteed that quick_ratio() <= real_quick_ratio()

Nope!  The docs don't say that, so it's not guaranteed.

It's not the _intent_ of the code that it be true, either.  The only point to quick_ratio() and real_quick_ratio() is speed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Fri May 14 21:23:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:23:00 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273864980.82.0.27640796902.issue8689@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You appear to be saying that the same code gives different results on 2.6.4 and 2.6.5. Correct? If so, did the version of sqlite change?

In any case, 3.1.2 on WinXP consistently gives (2,)
>>> sqlite3.version
'2.4.1'

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Fri May 14 21:27:08 2010
From: report at bugs.python.org (Simon Jagoe)
Date: Fri, 14 May 2010 19:27:08 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273865228.8.0.529362419571.issue8689@psf.upfronthosting.co.za>


Simon Jagoe <simon.jagoe at pragmagility.com> added the comment:

I will try to test this with the different combinations of python and sqlite versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Fri May 14 21:28:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 19:28:12 +0000
Subject: [issue8652] Minor improvements to the "Handling Exceptions" part of
	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1273865292.06.0.345590004997.issue8652@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The older exception catching syntax should not be promoted but could be mentioned, I agree. Adding a paragraph explaining why it was changed would do the trick.

Regarding the non-obviousness of which Python version the docs apply to, it is indeed mentioned on the front page of the docs, and repeated in the top-left corner of each page. You could propose making it bigger. Another way of doing this would be to have the page redirect to a URI that includes the version. That way, there would be another place to look for the version, and it would also make it easier to find out how to find the doc for other versions.

Last, exception unpacking being deprecated (because it?s horrible) and causing pain to newcomers seems a good reason to shot it down. Perhaps we should leave a short note about it, for people that get strange errors when using it inadvertently (or not getting an error where they thought they would).

I suggest you wait some more days for feedback from people with more experience with the docs. Sorry if my English was a bit convoluted :)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8652>
_______________________________________

From report at bugs.python.org  Fri May 14 21:34:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:34:34 +0000
Subject: [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273865674.33.0.60735603335.issue8694@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes, the faq entry has example code like
 "value = unicode(value, "utf-8")"
This whole section now applies when 'value' is a bytes or bytearray object and one calls str(value).

For portability, one should in 2.6/7 use unicode strings as much as possible and the bytes and unicode functions but not the str function. Then 2to3.py will change 'unicode' to 'str'. This should be a separate FAQ entry (if not already), for both 2.x and 3.x, with more complete advice from MLV (from whom I am parroting the above).

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8694>
_______________________________________

From report at bugs.python.org  Fri May 14 21:37:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 19:37:45 +0000
Subject: [issue8668] add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1273865865.87.0.582112260213.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have started to draft a similar proposal? but it seems that the wiki is not a communication medium as good as the bug tracker or the mailing lists (probably because of technical issues such as the lack of watchlist and e-mail notifications as much as because of Python culture). The discussion can happen here or on the mailing list unless Tarek firmly disagrees with the idea.

? http://wiki.python.org/moin/Distutils/Proposals/DevelopmentDistributions

----------
nosy: +merwok
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Fri May 14 21:40:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 19:40:10 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1273866010.44.0.561677030507.issue8679@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Fri May 14 21:43:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 19:43:52 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1273866232.78.0.584964862274.issue8680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What kind of sandbox should that be? Best-effort, meaning it replaces some functions to provide the dry-run feature, or an iron-clad sandbox that blocks malicious code from breaking out?

----------
nosy: +merwok
versions: +Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Fri May 14 21:47:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:47:28 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273866448.01.0.383023826006.issue8707@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Which is to say, the entire second paragraph beginning with 'number' should be deleted.  The same is true for 2.6, where it is also section 20.14, 3.1 (20.17), and 3.2 (19.17). Good catch. Thanks for reporting.

----------
keywords: +easy
nosy: +tjreedy
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Fri May 14 21:48:58 2010
From: report at bugs.python.org (angri)
Date: Fri, 14 May 2010 19:48:58 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273866538.18.0.224215786077.issue8689@psf.upfronthosting.co.za>


angri <general at angri.ru> added the comment:

This thread contains some observations of versions affected: http://groups.google.com/group/python-sqlite/browse_thread/thread/a53a5e5282e29318

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Fri May 14 21:59:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 19:59:31 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273867171.75.0.327212318951.issue8692@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


Removed file: http://bugs.python.org/file17338/factorial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 22:01:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 20:01:47 +0000
Subject: [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273867307.24.0.45248446466.issue8709@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given the mention of the posix example, I agree. The issue applies to 2.6 and 3.2 (that I checked) and so I assume to 2.7 and 3.1 also.

There is no doc string for devnull, which I presume should be in ntpath.

>>> help(os.devnull)
no Python documentation found for 'nul'

If this is a singular omission (as opposed to a general lack in that module), you might expand the patch to remedy that also.

----------
nosy: +tjreedy
stage:  -> commit review
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8709>
_______________________________________

From report at bugs.python.org  Fri May 14 22:03:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 20:03:37 +0000
Subject: [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273867417.33.0.137681534729.issue8649@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8649>
_______________________________________

From report at bugs.python.org  Fri May 14 22:04:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 20:04:25 +0000
Subject: [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273867307.24.0.45248446466.issue8709@psf.upfronthosting.co.za>
Message-ID: <4BEDACC5.9090307@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

os.devnull is a string, so ?pydoc os.devnull? will tell you about
strings, and ?help(os.devnull)? will be evaluated to
?help('/dev/null')? which won?t match any topic. Same thing with os.sep
and other module data; the doc is in the module?s docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8709>
_______________________________________

From report at bugs.python.org  Fri May 14 22:09:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 20:09:49 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273867789.31.0.14819870266.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I made a few minor updates to the patch.

It redefines partial_product to product(range(n, m, 2)), which saved me a few operations and is more Pythonic than what I had before. :-)

(Not quite what Alexander was after, but it's a step in the right direction.  His proposed defining of partial_product would have complicated my new base case.)

----------
Added file: http://bugs.python.org/file17345/factorial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 22:12:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 20:12:37 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273867957.9.0.656667270553.issue8677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is there any reason why you reported zlibmodule.c separately in #8650 (other than maybe finding that first), and for 4 versions there versus 1 here? Should this supersede that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Fri May 14 22:25:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 20:25:05 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273868705.2.0.71838251873.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The patch looks good.  Just one issue: I think the overflow check for num_operands * last_bit is bogus.  It's possible for the product to overflow and still end up being less than num_operands.  How about:

if (num_operands <= BITS_IN_LONG && num_operands * last_m_bit <= BITS_IN_LONG) ...

instead?  If num_operands <= BITS_IN_LONG then there's no danger of overflow in the multiplication, and if num_operands > BITS_IN_LONG then the second test will certainly fail.

Apart from that, and some very minor style issues (e.g., please put the body of an if statement on the following line;  I don't think this is codified in PEP7, but it seems to be the prevailing style in the Python codebase) I think the patch is good to go.

[Alexander]
"... benefit from redefining partial_product to be product(2*i+1 for i in range(start, stop))"

You mean rewriting to use half-open intervals [start, stop) rather than closed intervals?  In which case I agree it would look slightly cleaner that way, but I don't have particularly strong feelings on the issue.  I'll leave it up to Daniel whether he wants to change this or not.


"I would also reconsider the decision of using iterative outer loop."

I actually prefer the iterative version, perhaps out of a Python-bred aversion to recursion (in languages where the frames end up on the stack, anyway).  The bit_length calculation doesn't seem like a terrible price to pay to me.  Again, I leave this up to Daniel.


Marking this as accepted:  Daniel, if you like I can apply the overflow check change suggested above and the minor style fixes and apply this;  or if you want to go another round and produce a third patch, that's fine too.  Let me know.

(N.B.  If you do produce another patch, please name it something different and don't remove the earlier version---removing the earlier patch versions makes life harder for anyone trying to follow this issue.)

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 22:29:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 20:29:20 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273868960.26.0.755017884928.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Daniel, sorry:  I spent so long writing that last message that I didn't read your update until now.

The new patch looks fine;  same caveat about the overflow check as before.
Let me know when you want me to apply this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 22:31:50 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 20:31:50 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273869110.43.0.803100733882.issue8689@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The next question is whether there is any bug in the Python interface module or whether c.execute(s,t) is properly passing s and t to sqlite3 for processing and converting the return to a Python tuple. If the latter, then this should be closed as invalid (because it is a 3rd party problem).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Fri May 14 22:32:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 20:32:58 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273869178.67.0.282969997619.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One other note:  I find the bit numbering in find_last_set_bit peculiar:  isn't the least significant bit usually bit 0?  (Well, okay some people number the msb 0, but that's just weird. :)  I know the ffs and fls functions also start their bit numbering at one, but this seems very unconventional to me.

Perhaps rename find_last_set_bit to bit_length?  i.e., it's the *size* of the small bitfield that can contain the given value, rather than the index of the highest bit in that bitfield.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 22:44:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 20:44:44 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273869884.1.0.743471497745.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> it's the *size* of the small bitfield

*smallest

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 22:46:13 2010
From: report at bugs.python.org (Simon Jagoe)
Date: Fri, 14 May 2010 20:46:13 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273869973.02.0.918663723542.issue8689@psf.upfronthosting.co.za>


Simon Jagoe <simon.jagoe at pragmagility.com> added the comment:

Sorry for the waste of time. I have compiled Python 2.6.5 against sqlite3 3.6.22 (Lucid version) and 3.6.16-1ubuntu1 (Karmic version).

The test I posted originally fails with sqlite3 3.6.22 and passes with sqlite3 3.6.16-1ubuntu1, so it would appear to be a change in the library that is causing this error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Fri May 14 23:08:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 21:08:49 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1273871329.0.0.469538150916.issue2142@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Marking as a feature request:  I think this is somewhere on the line between bugfix and new feature, but either way 2.7 is too close to release to start messing with something that isn't really all that broken.

For 2.7 (and 2.6, 3.1), there's also the option of updating the documentation to point out this issue.  It would also be worth updating the command-line-interface example in the docs to do this post-processing (i.e., for each line that doesn't end in a newline, add '\n\ No newline at end of file') before calling writelines.

----------
type: behavior -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Fri May 14 23:17:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 21:17:00 +0000
Subject: [issue8689] sqlite3 parameter substitution breaks with multiple
	parameters
In-Reply-To: <1273595222.03.0.475415636905.issue8689@psf.upfronthosting.co.za>
Message-ID: <1273871820.01.0.239110851571.issue8689@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given that this is a real, and disconcerting problem, and not a failure to read the doc, no apology needed. At least one solution is recorded here for anyone else hitting the same problem.

If anyone thinks there should be a change to the sqlite3 module, they can reopen this.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8689>
_______________________________________

From report at bugs.python.org  Fri May 14 23:22:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 21:22:46 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273872166.85.0.605712290877.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Conditions to reproduce the bug:
 - non ASCII directory
 - don't use make -j N (no MAKEFLAGS environment variable)
 - write make output into a pipe, eg. make 2>&1|cat

My 2 last patches are not enough: there are other functions writing non-ASCII strings to log whereas log encoding is ASCII. The right fix is to use the backslashreplace error handler for the log. Two solutions:
 a) replace sys.stdout by a new file using backslashreplace: I tried this solution for regrtest.py: #8533. My patch for regrtest.py doesn't work on Windows because of a newline issue
 b) emulate backslashreplace only in distutils log

I prefer (a) because it can be implemented in setup.py without touching distutils (tarek told me that distutils shouldn't be patched too much).

distutils_log_backslashreplace.patch implements (b).

----------
Added file: http://bugs.python.org/file17346/distutils_log_backslashreplace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Fri May 14 23:28:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 14 May 2010 21:28:00 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273872480.94.0.839964343268.issue8663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I'll look at that asap. Although, all these patchs should have some tests demonstrating the bugs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Fri May 14 23:31:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 21:31:42 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1273872702.04.0.294846263026.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

setup_stdout_backslashreplace.patch implements point (a).

I don't know which solution is better. This issue is not specific to compiling CPython, other programs may fail in non-ASCII paths and so solution (b) is maybe better.

----------
Added file: http://bugs.python.org/file17347/setup_stdout_backslashreplace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Fri May 14 23:32:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 May 2010 21:32:39 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1273872759.87.0.37477841923.issue8677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is there any reason why you reported zlibmodule.c separately in #8650
> (other than maybe finding that first),

Because zlibmodule.c has more 64-bitness issues than just PY_SSIZE_T_CLEAN (see bug description).

> Should this supersede that?

No.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Fri May 14 23:36:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 14 May 2010 21:36:00 +0000
Subject: [issue8718] subprocess: NameError: name 'WaitForSingleObject' is not
	def
In-Reply-To: <1273872959.97.0.102305569276.issue8718@psf.upfronthosting.co.za>
Message-ID: <1273872959.97.0.102305569276.issue8718@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

This was a regression due to a commit made less than 2 days ago.

make: [build_pywin32] running 'F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun
\python\PCbuild\amd64\python.exe setup.py build' in 'build\pyhg_trunk-win64-x64-
hgtip27-rrun\pywin32'
Traceback (most recent call last):
  File "setup.py", line 83, in <module>
    from distutils.command.build_ext import build_ext
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\distutils\c
ommand\build_ext.py", line 23, in <module>
    from distutils.msvccompiler import get_build_version
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\distutils\m
svccompiler.py", line 657, in <module>
    from distutils.msvc9compiler import MSVCCompiler
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\distutils\m
svc9compiler.py", line 18, in <module>
    import subprocess
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\subprocess.
py", line 611, in <module>
    class Popen(object):
  File "F:\as\apy\build\pyhg_trunk-win64-x64-hgtip27-rrun\python\lib\subprocess.
py", line 911, in Popen
    _WaitForSingleObject=WaitForSingleObject,
NameError: name 'WaitForSingleObject' is not defined

----------
components: Library (Lib)
messages: 105768
nosy: srid
priority: normal
severity: normal
status: open
title: subprocess: NameError: name 'WaitForSingleObject' is not def
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8718>
_______________________________________

From report at bugs.python.org  Fri May 14 23:37:42 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 14 May 2010 21:37:42 +0000
Subject: [issue8718] subprocess: NameError: name 'WaitForSingleObject' is not
	def
In-Reply-To: <1273872959.97.0.102305569276.issue8718@psf.upfronthosting.co.za>
Message-ID: <1273873062.52.0.0230113407622.issue8718@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

+brett

http://svn.python.org/view/python/trunk/Lib/subprocess.py?r1=80496&r2=81154

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8718>
_______________________________________

From report at bugs.python.org  Fri May 14 23:38:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 14 May 2010 21:38:52 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273868705.2.0.71838251873.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTilmG9nnOvhveowNLh0Mzvc579CDpSNtIFq7fQAq@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

On Fri, May 14, 2010 at 3:25 PM, Mark Dickinson <report at bugs.python.org> wrote:
> The patch looks good. ?Just one issue: I think the overflow check for num_operands * last_bit is bogus. ?It's possible for the product to overflow and still end up being less than num_operands. ?How about:

You're right; I'm not sure what I was thinking. (actually, I'm pretty
sure I was thinking about addition ;) )

> if (num_operands <= BITS_IN_LONG && num_operands * last_m_bit <= BITS_IN_LONG) ...
>
> instead? ?If num_operands <= BITS_IN_LONG then there's no danger of overflow in the multiplication, and if num_operands > BITS_IN_LONG then the second test will certainly fail.

Yes, that looks good.

> Marking this as accepted: ?Daniel, if you like I can apply the overflow check change suggested above and the minor style fixes and apply this; ?or if you want to go another round and produce a third patch, that's fine too. ?Let me know.

That would be great. :)

With regards to find_last_set_bit, I understand where you're coming
from, but I'm following the convention of ffs/fls and also
bits_in_digit() from longobject.c.  I'd like to keep them
interchangeable, in case they're consolidated at some point in the
future.  If you want to rename the function, that's fine with me.

FWIW, I think the MSB=0th people are all electrical engineers.  If
you're serializing down to bits and the MSB is the first (0th) bit off
the wire, it makes sense in that context.

> (N.B. ?If you do produce another patch, please name it something different and don't remove the earlier version---removing the earlier patch versions makes life harder for anyone trying to follow this issue.)

Good to know.  I'll keep that in mind going forward.

Thanks to both of you for the rigorous review.  This was a fun patch
to work on. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Fri May 14 23:57:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 21:57:39 +0000
Subject: [issue5099] subprocess.Popen.__del__ causes AttributeError (os module
	== None)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1273874259.74.0.505923111488.issue5099@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fix _internal_poll() on Windows: r81179 (trunk), r81181 (2.6), r81181 (3.x), r81182 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Fri May 14 23:58:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 21:58:50 +0000
Subject: [issue8717] Subprocess.py broken in trunk
In-Reply-To: <1273862076.01.0.24732603883.issue8717@psf.upfronthosting.co.za>
Message-ID: <1273874330.63.0.370334880324.issue8717@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thank you for your patch: I closed #5099 regression.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8717>
_______________________________________

From report at bugs.python.org  Fri May 14 23:59:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 21:59:22 +0000
Subject: [issue8718] subprocess: NameError: name 'WaitForSingleObject' is not
	def
In-Reply-To: <1273872959.97.0.102305569276.issue8718@psf.upfronthosting.co.za>
Message-ID: <1273874362.49.0.104755763617.issue8718@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #5099 (and #8717). It should be fixed now.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8718>
_______________________________________

From report at bugs.python.org  Sat May 15 00:16:37 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Fri, 14 May 2010 22:16:37 +0000
Subject: [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1273875397.8.0.200812881784.issue6610@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

I think if the test is conducted without closing stderr, it will only check that stdin/stdout are handled correctly (you could assume that if one handled stdin/stdout correctly, they did the same with stderr).

However, since I've used a context manager (_NoStandardFds) to handle the closing/restoration of the standard fds, I think the benefit (fuller test coverage) outweighs the cost (potentially harder debugging if there's a problem with the test); if I'm not mistaken, the context manager should restore your fds before the default exception handler writes to stdout (at least in the parent and the child prior to exec()).

n.b.: I've also created a Rietveld issue for this patch: http://codereview.appspot.com/1227041/show

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________

From report at bugs.python.org  Sat May 15 00:19:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 22:19:41 +0000
Subject: [issue8719] buildbot: segfault on FreeBSD (signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

There are segfaults on x86 FreeBSD 7.2 3.x. It looks like it's a regression introduced by r80876.

---

Build 556:
...
test_coding
test_hash
test_strtod
test_float
test_runpy
*** Signal 11

Build 555:
...
test_int
test_smtplib
test_asynchat
test_runpy
*** Signal 11

Build 554:
...
test_lib2to3
test_pickle
test_xml_etree
test_sys
[34438 refs]
[34470 refs]
[34728 refs]
[34468 refs]
*** Signal 11

Build 553:
...
test_robotparser
test_plistlib
test_signal
test_runpy
*** Signal 11

Build 552:
...
test_importlib
test_crypt
test_sort
test_runpy
*** Signal 11

Build 551:
...
./python -E -c 'import sys ; from sysconfig import get_platform ; print(get_platform()+"-"+sys.version[0:3])' >platform
[34466 refs]
./python -Wd -E -bb ./Lib/test/regrtest.py -uall -rwW -l 
== CPython 3.2a0 (py3k:81134, May 13 2010, 14:25:32) [GCC 4.2.1 20070719 [FreeBSD]]
==   FreeBSD-7.2-RELEASE-i386-32bit-ELF
==   /usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/build/test_python_22056
Using random seed 3201291
test_exceptions
*** Signal 11

Build 550:
...
test_codecencodings_tw
test_zipfile
test_import
test_exceptions
*** Signal 11

Build 549:
...
test___future__
test_smtpnet
test_exceptions
*** Signal 11

(...)

Build 530 (r80876): ... signal 11
(Build 526..529 failed with svn exceptions)
Build 525 (r80775) didn't crashed.

----------
messages: 105775
nosy: haypo
priority: normal
severity: normal
status: open
title: buildbot: segfault on FreeBSD (signal 11)
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8719>
_______________________________________

From report at bugs.python.org  Sat May 15 00:59:55 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 14 May 2010 22:59:55 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Somewhere between python 3.0.1 and 3.1.2 the behaviour of inspect.findsource changed: it does not find the source code anymore for a code object whose filename/source is in the linecache.cache because instead of the previous::

    file = getsourcefile(object) or getfile(object)

it only does now::

    file = getsourcefile(object) 

IMO it is enough if findsource() raises if it can't eventually discover the source code - i don't see the need to do this ahead.

In any case, the r312 findsource version requires an ugly work around within py.test in order for it to continue to be able to use the inspect module with dynamically compiled code.  The underlying issue is that at code-compile time no sensible (PEP302 compliantly loaded) module can be constructed because this is only known at exec-time but this is not part of the test tool API and is done somewhere in user code. 

Proposed fix: revert to r301 behaviour and add back "or getfile(object)" to the first line of inspect.findsource()

----------
components: Library (Lib)
messages: 105776
nosy: benjamin.peterson, hpk
priority: normal
severity: normal
status: open
title: undo findsource regression/change
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Sat May 15 01:42:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 May 2010 23:42:16 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273880536.1.0.648487000916.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, here's what I'm planning to commit (tomorrow), in case anyone wants to give it one last check.  I've added some comments half-explaining the algorithm used (just in case the referenced URL goes out of existence).  I made a couple of other minor changes to the algorithm:

(1) in factorial_partial_product, use 'k = (n + num_operands) | 1;' rather than 'k = (n + num_operands - 1) | 1;'.  This saves an operation, and means that when a range including an odd number of terms is split then the bottom half gets the extra term, which makes the partial products a teensy bit more balanced, since the bottom half consists of smaller numbers.

(2) in factorial_loop, I set the initial value of 'upper' to 3 rather than 1.  This avoids factorial_partial_product ever being called with a start of 1.

Apart from that, no significant changes.

----------
assignee: stutzbach -> mark.dickinson
Added file: http://bugs.python.org/file17348/factorial2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 01:47:15 2010
From: report at bugs.python.org (Trundle)
Date: Fri, 14 May 2010 23:47:15 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1273880835.95.0.133855231267.issue8720@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

This was changed due to issue #4050.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Sat May 15 02:10:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 00:10:05 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273882205.03.0.692521436615.issue8715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Notes for myself:
 - "Encodes" and "fallback" in .h documentation  => "Encode", "fall back"
 - bootstrap failure on Windows: import did use default error handler, it uses surrogateescape error handler, but PyUnicode_EncodeString() doesn't have codec "fast-path" for MBCS+surrogateescape.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Sat May 15 02:47:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 00:47:16 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1273884436.31.0.982377438474.issue8720@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Sat May 15 03:36:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 May 2010 01:36:29 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1273887389.88.0.255676043445.issue8720@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As I remember it, #4050 was in turn caused by a change elsewhere in the codebase to using linecache where it wasn't used before.

Regardless, though, the problem is that findsource doesn't produce an error when called on a binary module. It thinks it found the source code, but what it found was binary data.

@holger: can you suggest an alternate fix to #4050?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Sat May 15 03:43:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 01:43:37 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1273887817.83.0.365317892423.issue3605@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed the new test for Windows: r81183 (py3k). The new test failed on Windows because of the different newline characters:

Traceback (most recent call last):
  File "...\test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Fatal Python error: PyThreadState_Get: no current thread\r\n' != b'Fatal Python error: PyThreadState_Get: no current thread\n'

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Sat May 15 04:11:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 02:11:30 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1273889490.36.0.562938319687.issue8716@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sat May 15 04:14:30 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 15 May 2010 02:14:30 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273889670.48.0.0652490268614.issue8692@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 04:18:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 02:18:26 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273880536.1.0.648487000916.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTil4WYrzfr0JY6ky8MV4idSBwlxNz3T_hxiSr3GW@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark, It is always a pleasure to read your algorithm descriptions!

Just a few comments:

- It would be nice if a pure python implementation would make it
somewhere in the code base.  Maybe it can be placed in comments in C
file or added to the test module somehow.

- Please rename arguments to factorial_partial_product() from n, m to
start, stop.   It is confusing enough that n has a different meaning
loop() and partial_product(), but n, m coming in reverse alphabetical
order makes it really hard to follow the code.

- Using n as a variable in the fast loop saves one integer assignment
(likely to be optimized away) at the expense of clarity.    One has to
realize that there is an unconditional return after the loop before
concluding that n is the same in the recursive part.

- "We know that m is the largest number to be multiplied."  Shouldn't
that be m - 2?

- Is find_last_set_bit() the same as bit_length()?  If so, why isn't
it called the same?   I don't want to bikeshed, but seeing
find_last_set_bit makes me wonder if "last" means most or least
significant bit.

- There is a comment line /* r *= inner; */ in factorial_loop() but no
r variable.  Shouldn't that be outer *= inner?

I'll review math_factorial() after reading Daniel's message that just arrived.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 04:27:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 02:27:58 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <AANLkTil4WYrzfr0JY6ky8MV4idSBwlxNz3T_hxiSr3GW@mail.gmail.com>
Message-ID: <AANLkTikp1cZcosjL5gJJKuKA6MMek8XoU9oxGefrteHQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Some more ...

- Mark's notes talk about "odd-part-of-factorial".  It would be
clearer if r variable in math_factorial() was called odd_part.

- I would also rename nminusnumbits to ntwos or something else that
explains what it is rather than how it is computed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 04:28:53 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 02:28:53 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

[storage at nas0 ~]$ python2.6 -c "import urlparse; print urlparse.urlsplit('http://www.famfamfam.com](http://www.famfamfam.com/', 'http', True)"
SplitResult(scheme='http', netloc='www.famfamfam.com](http:', path='//www.famfamfam.com/', query='', fragment='')
[storage at nas0 ~]$ python2.7 -c "import urlparse; print urlparse.urlsplit('http://www.famfamfam.com](http://www.famfamfam.com/', 'http', True)"
('urlsplit() - %s, scheme=%s, allow_fragments=%s', 'http://www.famfamfam.com](http://www.famfamfam.com/', 'http', True)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/apy/APy27/lib/python2.7/urlparse.py", line 184, in urlsplit
    raise ValueError("Invalid IPv6 URL")
ValueError: Invalid IPv6 URL
[storage at nas0 ~]$

via http://bitbucket.org/tarek/distribute/issue/160

----------
components: Library (Lib)
messages: 105785
nosy: srid
priority: normal
severity: normal
status: open
title: urlparse.urlsplit regression in 2.7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Sat May 15 04:40:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 May 2010 02:40:33 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1273891233.02.0.361644513209.issue8721@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why do you think this is a regression?  It looks to me like the error message is accurate.  (A ']' is valid in the netloc part only when specifying an IPv6 address).

----------
nosy: +orsenthil, r.david.murray
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Sat May 15 04:56:13 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 02:56:13 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1273892173.68.0.0383193063564.issue8721@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Shouldn't `urlparse` accept non-IPv6 URLs as well - as it always used to - when these URLs can have a single ']'?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Sat May 15 04:58:09 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 02:58:09 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1273892289.55.0.160346206793.issue8721@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

For eg., the following URLs seems to load just fine in my browser:

  http://www.google.com/search?q=foo&b=df]d&qscrl=1

And, as is the case with the django-cms PyPI page (see referred issue link in msg), such URLs seemed to be practically used in a few places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Sat May 15 05:15:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 May 2010 03:15:01 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1273893301.17.0.843509125759.issue8721@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python 2.7b2+ (trunk:81129, May 12 2010, 19:05:17) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urlparse import urlsplit
>>> urlsplit('http://www.google.com/search?q=foo&b=df]d&qscrl=1', 'http', True)
SplitResult(scheme='http', netloc='www.google.com', path='/search', query='q=foo&b=df]d&qscrl=1', fragment='')

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Sat May 15 06:10:59 2010
From: report at bugs.python.org (Paul Davis)
Date: Sat, 15 May 2010 04:10:59 +0000
Subject: [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>


New submission from Paul Davis <paul.joseph.davis at gmail.com>:

The docs for __getattr__ in the object model section could be more specific on the behavior when a @property raises an AttributeError and there is a custom __getattr__ defined. Specifically, it wasn't exactly clear that __getattr__ would be invoked after a @property was found and evaluated.

The attached script demonstrates the issue on OS X 10.6, Python 2.6.1

I'm thinking something along the lines of:

If the attribute search encounters an AttributeError (perhaps due to a @property raising the error) the search is considered a failure and __getattr__ is invoked.

----------
assignee: docs at python
components: Documentation
files: example.py
messages: 105790
nosy: Paul.Davis, docs at python
priority: normal
severity: normal
status: open
title: Documentation for __getattr__
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file17349/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Sat May 15 06:13:33 2010
From: report at bugs.python.org (Paul Davis)
Date: Sat, 15 May 2010 04:13:33 +0000
Subject: [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1273896813.99.0.937519179401.issue8722@psf.upfronthosting.co.za>


Paul Davis <paul.joseph.davis at gmail.com> added the comment:

I should mention, in example.py, it wasn't immediately clear that "print f.bing" would actually print instead of raising the AttributeError. As in, I had a property raising an unexpected error that happend to be an AttributeError. If its not an attribute error, the error is not swallowed. I can see the obvious argument for "AttributeError means not found", it just wasn't immediately obvious what was going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Sat May 15 06:49:25 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 15 May 2010 04:49:25 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273898965.97.0.563921326182.issue8713@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santa.ant at me.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Sat May 15 08:02:46 2010
From: report at bugs.python.org (James Morgan)
Date: Sat, 15 May 2010 06:02:46 +0000
Subject: [issue8723] IDLE won't start import os error
In-Reply-To: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>
Message-ID: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>


New submission from James Morgan <jmorg1989 at gmail.com>:

Hi,

For some reason I have recently lost the ability to open IDLE for python 2.6.2.

I was able to open it for 2.5 without issue. I reinstalled 2.6.2 several times, removed 2.5, tried 2.6.5 instead, still cannot load IDLE. I can load the python command prompt however.

When attempting to run idle through cmd.exe I get an error in line 3 of pyshell.py

"import os
ImportError: No module named os"

Any help on this issue would be greatly appreciated.

----------
components: IDLE
messages: 105792
nosy: gromij
priority: normal
severity: normal
status: open
title: IDLE won't start import os error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8723>
_______________________________________

From report at bugs.python.org  Sat May 15 09:11:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 15 May 2010 07:11:58 +0000
Subject: [issue8723] IDLE won't start import os error
In-Reply-To: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>
Message-ID: <1273907518.57.0.607951105617.issue8723@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug in Python? It rather sounds like you misconfigured your system somehow. Without access to the system, it is difficult to guess what the misconfiguration might be, though.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8723>
_______________________________________

From report at bugs.python.org  Sat May 15 09:26:20 2010
From: report at bugs.python.org (holger krekel)
Date: Sat, 15 May 2010 07:26:20 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1273908380.8.0.120496139103.issue8720@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

Thanks for helping with this!  Attached is a patch that adds a keyword "check=True" to getsourcefile so that findsource can defer existence-checking until after cache lookup.  Eventually, findsource will still raise an IOError if it can't find the source file and cannot recover the source from cache.  The patch mainly consists of adding a number of tests to specify the (refined) behaviour of findsource and getsourcefile.  

best, holger

----------
keywords: +patch
Added file: http://bugs.python.org/file17350/findsource.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Sat May 15 09:52:26 2010
From: report at bugs.python.org (James Morgan)
Date: Sat, 15 May 2010 07:52:26 +0000
Subject: [issue8723] IDLE won't start import os error
In-Reply-To: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>
Message-ID: <1273909946.82.0.628610923926.issue8723@psf.upfronthosting.co.za>


James Morgan <jmorg1989 at gmail.com> added the comment:

Thanks for the reply.

I have used idle before on this system without issue, and since 2.5 worked I figured there was some difference between 2.5 and 2.6 which was causing the issue.

I have found since that the issue is likely not with idle at all however, but rather with the modules... while the python command line works I am unable to use it to run one of my scripts. Attempting to run through cmd revealed that it was failing as it could not import shutil.

I am new to this help system so apologies if i have miscategorised this issue. Since it seems the nature of the problem is not what I initially thought I will move it to extension modules.

I have no idea if it is relevant, but I am running on XP pro SP3.

Thanks

----------
components: +Extension Modules -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8723>
_______________________________________

From report at bugs.python.org  Sat May 15 09:53:06 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 15 May 2010 07:53:06 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1273909986.66.0.699985624158.issue7640@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hello

I advocate the inclusion of this patch to the 2.6 maintenance branch, because currently the io module in this branch (which is still the most recent 2.X version released) is simply broken. 
People using it will certainly encounter MAJOR file corruptions due to the buggy seek().

Or should we rather backport the much more evoluated io of trunk to py2.6 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7640>
_______________________________________

From report at bugs.python.org  Sat May 15 12:32:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 10:32:07 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273919527.19.0.894385195397.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

New patch (factorial3.patch) addressing all of Alexander's points except the one about including Python source somewhere.

I also expanded the lookup table to 20 entries on LP64 systems.

----------
Added file: http://bugs.python.org/file17351/factorial3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 12:33:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 15 May 2010 10:33:49 +0000
Subject: [issue8723] IDLE won't start import os error
In-Reply-To: <1273909946.82.0.628610923926.issue8723@psf.upfronthosting.co.za>
Message-ID: <4BEE788A.3070000@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I am new to this help system

Please understand that this is not a help system at all.
Instead, it is a bug tracker: a way for people to contribute
to Python, by reporting bugs or contributing code. For help,
please contact one of the Python help forums, such as
python-list at python.org (aka news:comp.lang.python).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8723>
_______________________________________

From report at bugs.python.org  Sat May 15 13:10:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 15 May 2010 11:10:31 +0000
Subject: [issue8712] Skip libpthread related test failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273921831.57.0.828421115527.issue8712@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I can't pinpoint the exact causes for each individual test failure. I assumed that they are caused by threading/signal issues, because the tests pass when Python is compiled --without-threads.


But here's a list of possible culprits for future reference:

[pthread's execve(2) breaks close(2)]
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6183

[SIGCHLD handler is called at bad timing when linked to libpthread]
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6273

[pthread: 100% CPU usage after execv]
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6376

[pthread: file descriptors are "pseudo-blocking"]
http://www.mail-archive.com/misc at openbsd.org/msg80643.html

[test_siginterrupt_off broken by libpthread's internal hooking of signals]
[test_itimer_prof broken by libpthread's internal use of SIGPROF]
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_signal_py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8712>
_______________________________________

From report at bugs.python.org  Sat May 15 13:28:26 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 15 May 2010 11:28:26 +0000
Subject: [issue8712] Skip libpthread related test failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273922906.39.0.775096043033.issue8712@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The FreeBSD-6.4-RELEASE-i386 buildbot has similar libpthread issues.

This is just in:

======================================================================
FAIL: test_send_signal (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_subprocess.py", line 770, in test_send_signal
    self.assertIn(b'KeyboardInterrupt', stderr)
AssertionError: b'KeyboardInterrupt' not found in b''


Re documentation:

Another approach would be to configure builds on systems with known
threading issues --without-threads by default. Advantages:

  a) Users will be immediately aware of the issues.

  b) Less work with the FreeBSD-6.4 buildbot.

  c) The --without-threads path is actually tested regularly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8712>
_______________________________________

From report at bugs.python.org  Sat May 15 13:43:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 11:43:36 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273923816.97.0.984291806584.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And the same patch, but with a (deliberately simple) pure Python version of the algorithm in test_math.py.

----------
Added file: http://bugs.python.org/file17352/factorial4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 13:47:50 2010
From: report at bugs.python.org (James Morgan)
Date: Sat, 15 May 2010 11:47:50 +0000
Subject: [issue8723] IDLE won't start import os error
In-Reply-To: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>
Message-ID: <1273924070.63.0.0155206343145.issue8723@psf.upfronthosting.co.za>


James Morgan <jmorg1989 at gmail.com> added the comment:

Sorry, I guess I misunderstood the function as I saw some issues which appeared similar in style to my own.

Never mind this then I will seek help elsewhere. Thankyou.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8723>
_______________________________________

From report at bugs.python.org  Sat May 15 13:48:09 2010
From: report at bugs.python.org (James Morgan)
Date: Sat, 15 May 2010 11:48:09 +0000
Subject: [issue8723] IDLE won't start import os error
In-Reply-To: <1273903366.17.0.918420762787.issue8723@psf.upfronthosting.co.za>
Message-ID: <1273924089.76.0.266411447358.issue8723@psf.upfronthosting.co.za>


Changes by James Morgan <jmorg1989 at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8723>
_______________________________________

From report at bugs.python.org  Sat May 15 14:22:07 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 15 May 2010 12:22:07 +0000
Subject: [issue8724] bind_and_activate parameter is missed from directive
In-Reply-To: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>
Message-ID: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/simplexmlrpcserver.html#SimpleXMLRPCServer.SimpleXMLRPCServer

bind_and_activate parameter is described but not defined in directive.

----------
messages: 105803
nosy: naoki
priority: normal
severity: normal
status: open
title: bind_and_activate parameter is missed from directive

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8724>
_______________________________________

From report at bugs.python.org  Sat May 15 14:22:47 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 15 May 2010 12:22:47 +0000
Subject: [issue8724] bind_and_activate parameter is missed from directive
In-Reply-To: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>
Message-ID: <1273926167.01.0.357373923637.issue8724@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8724>
_______________________________________

From report at bugs.python.org  Sat May 15 14:39:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 12:39:06 +0000
Subject: [issue8725] Python3: use ASCII for the file system encoding on
	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I introduced initfsencoding() in #8610 to ensure that Py_FileSystemEncoding is not more NULL. In the discussion, Marc Lemburg noticed that falling back the UTF-8 on nl_langinfo(CODESET) error is a bad idea: ASCII is better (I agree).

We cannot fall back to ASCII yet because there are two other problems that have to be fixed before that:

 - Python3 doesn't support surrogates in module filenames: see #8611
 - If Py_FileSystemEncoding is NULL, encoding functions fallback to utf-8 (PyUnicode_GetDefaultEncoding()). #8715 proposes a new PyUnicode_EncodeFSDefault() function to fix this problem

Attached patch is a partial fix for this issue.

----------
components: Interpreter Core, Unicode
files: fsencoding_ascii.patch
keywords: patch
messages: 105804
nosy: haypo
priority: normal
severity: normal
status: open
title: Python3: use ASCII for the file system encoding on initfsencoding() failure
versions: Python 3.2
Added file: http://bugs.python.org/file17353/fsencoding_ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8725>
_______________________________________

From report at bugs.python.org  Sat May 15 14:39:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 12:39:46 +0000
Subject: [issue8610] Python3/POSIX:  errors if file system encoding is None
In-Reply-To: <1272974338.7.0.0380929022736.issue8610@psf.upfronthosting.co.za>
Message-ID: <1273927186.92.0.695442514669.issue8610@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited the last patch (fall back to UTF-8): r81190 (3.x), blocked in 3.1 (r81191).

I opened a new issue for the UTF-8/ASCII fallback: #8725, because the ASCII fallback is a different issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8610>
_______________________________________

From report at bugs.python.org  Sat May 15 14:40:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 12:40:20 +0000
Subject: [issue8725] Python3: use ASCII for the file system encoding on
	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1273927220.18.0.986766444321.issue8725@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +Create PyUnicode_EncodeFSDefault() function, Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)
nosy: +Arfrever, lemburg, loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8725>
_______________________________________

From report at bugs.python.org  Sat May 15 14:47:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 12:47:42 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273919527.19.0.894385195397.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTinlk7FVFR5FFeDQiHUwV_RMtf7CaYI7N26xQhgE@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 15, 2010 at 6:32 AM, Mark Dickinson <report at bugs.python.org> wrote:
> New patch (factorial3.patch) addressing all of Alexander's points except the one about including Python source somewhere.

Thanks for making the changes.  I think we converged to a really neat
implementation.

>
> I also expanded the lookup table to 20 entries on LP64 systems.
>

It's a matter of taste, but I was taught that C allows trailing commas
in initializers specifically for the cases like this to avoid using a
leading comma.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 14:54:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 12:54:52 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273928092.06.0.144733172284.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It's a matter of taste, but I was taught that C allows trailing commas
> in initializers specifically for the cases like this to avoid using a
> leading comma.

Unfortunately, I think C89 doesn't allow for this, and there are tracker issues about Python compiles failing on some platforms (AIX?) thanks to extra trailing commas in the source.  I prefer the extra comma too, but it's not legal C89.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 15:03:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 13:03:43 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273928623.2.0.911811863736.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah;  Alexander's right:  I was misremembering.  An extra comma in an *enum* list isn't allowed (cf. issue 5889);  an extra comma in an array initializer is.  I'll rewrite that bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 15:17:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 13:17:16 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273929436.08.0.27888195192.issue8715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> bootstrap failure on Windows: import did use default error handler, 
> it uses surrogateescape error handler, but PyUnicode_EncodeString()
> doesn't have codec "fast-path" for MBCS+surrogateescape.

I enabled "shortcuts" in PyUnicode_EncodeString() for any error handler (not only the default error handler, strict) in r81192.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Sat May 15 15:23:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 13:23:19 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273929799.16.0.0358701001237.issue8715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyUnicode_AsEncodedString() contains a special path for the file system encoding. I don't think that it is still needed, but I don't know how to check that.

    /* During bootstrap, we may need to find the encodings
       package, to load the file system encoding, and require the
       file system encoding in order to load the encodings
       package.

       Break out of this dependency by assuming that the path to
       the encodings module is ASCII-only.  XXX could try wcstombs
       instead, if the file system encoding is the locale's
       encoding. */
    else if (Py_FileSystemDefaultEncoding &&
             strcmp(encoding, Py_FileSystemDefaultEncoding) == 0 &&
             !PyThreadState_GET()->interp->codecs_initialized)
        return PyUnicode_EncodeASCII(PyUnicode_AS_UNICODE(unicode),
                                     PyUnicode_GET_SIZE(unicode),
                                     errors);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Sat May 15 15:45:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 13:45:34 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273923816.97.0.984291806584.issue8692@psf.upfronthosting.co.za>
Message-ID: <A0D8ADA7-80CB-4A0E-89F0-8D6A112F0323@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

There is one place in the notes still referring to  
factorial_part_product.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 16:14:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 15 May 2010 14:14:11 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273919527.19.0.894385195397.issue8692@psf.upfronthosting.co.za>
Message-ID: <AANLkTim0R_79EfZhWFgqeV0EanL2LmcI-SJlIv2yOSXo@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

The comment for bit_length is missing a space or two:
"Objects/longobject.c.Someday"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 16:27:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 14:27:05 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273933625.16.0.890539095032.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> There is one place in the notes still referring to
> factorial_part_product.

Hmm.  I can't find it.  Can you be more specific?

I'll fix the spaces before 'Someday'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 17:12:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 15:12:56 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273933625.16.0.890539095032.issue8692@psf.upfronthosting.co.za>
Message-ID: <84E6E88B-6F4C-4100-8329-68810307B872@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Sorry for terseness. Sending it from my phone.

The line was in factorial4.patch:

+ * The factorial_partial_product function computes the product of all  
odd j in

>>
>
> Hmm.  I can't find it.  Can you be more specific?
>
>

----------
Added file: http://bugs.python.org/file17354/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________
-------------- next part --------------
<html><body bgcolor="#FFFFFF"><div>Sorry for terseness. Sending it from my phone.&nbsp;</div><div><br></div><div>The line was in factorial4.patch:</div><div><br></div><div><span class="Apple-style-span" style="font-family: Times; font-size: 16px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><pre style="word-wrap: break-word; white-space: pre-wrap; ">+ * The factorial_partial_product function computes the product of all odd j in</pre><pre style="word-wrap: break-word; white-space: pre-wrap; "><br></pre><pre style="word-wrap: break-word; white-space: pre-wrap; "><br></pre></span><br><br></div><blockquote type="cite"><div><blockquote type="cite"><span class="Apple-style-span" style="color: rgb(0, 0, 0);"><br></span></blockquote><span></span><br><span>Hmm. &nbsp;I can't find it. &nbsp;Can you be more specific?</span><br><span></span><br><br><
 /div></blockquote></body></html>

From report at bugs.python.org  Sat May 15 17:16:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 15:16:28 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273936588.72.0.397583525141.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, thanks.  I'm still not seeing what's wrong with this, though  (sorry for being slow :(  )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 17:22:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 15:22:31 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273936588.72.0.397583525141.issue8692@psf.upfronthosting.co.za>
Message-ID: <0F2418CA-345C-4C3B-8186-52043F39B1F2@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

s/partial_product/odd_part/

It looks like you made this change in some places but not all.

On May 15, 2010, at 11:16 AM, Mark Dickinson <report at bugs.python.org>  
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Okay, thanks.  I'm still not seeing what's wrong with this, though   
> (sorry for being slow :(  )
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8692>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 17:26:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 May 2010 15:26:36 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273937196.27.0.522647777711.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

But factorial_partial_product and factorial_odd_part both exist:  the former is just computing the product of all odd integers in the given interval, while the latter computes the odd part of factorial(n).

I've double checked the comments and they still look okay to me.  That particular reference really is to factorial_partial_product.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 18:08:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 15 May 2010 16:08:25 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273937196.27.0.522647777711.issue8692@psf.upfronthosting.co.za>
Message-ID: <C3BCC6B3-F558-47F8-913E-E0BF341DB38A@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Sorry I didn't realize that ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sat May 15 18:28:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 16:28:42 +0000
Subject: [issue8715] Create PyUnicode_EncodeFSDefault() function
In-Reply-To: <1273856034.98.0.139429807226.issue8715@psf.upfronthosting.co.za>
Message-ID: <1273940922.93.0.836546311969.issue8715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited as r81194 (py3k), blocked in 3.1 (r81195).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8715>
_______________________________________

From report at bugs.python.org  Sat May 15 18:34:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 May 2010 16:34:21 +0000
Subject: [issue8725] Python3: use ASCII for the file system encoding on
	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1273941261.49.0.945653451868.issue8725@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

PyUnicode_AsEncodedString() contains a special path for the file system encoding. I don't think that it is still needed, but I don't know how to check that. => read msg105810

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8725>
_______________________________________

From report at bugs.python.org  Sat May 15 22:11:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 15 May 2010 20:11:23 +0000
Subject: [issue8708] OpenID blunder
In-Reply-To: <AANLkTikxYcJh5V8g22jQBc4fE-_NRbnEP-7MTVl8MYd9@mail.gmail.com>
Message-ID: <1273954283.3.0.788493041404.issue8708@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Since Martin seemed to fix this, closing the issue.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8708>
_______________________________________

From report at bugs.python.org  Sat May 15 22:33:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 20:33:39 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1273955619.69.0.3621525916.issue7640@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r81203. Thank you, Pascal!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7640>
_______________________________________

From report at bugs.python.org  Sat May 15 22:53:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 20:53:38 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1273956818.32.0.786833508331.issue8685@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The current patch gives much smaller benefits than the originally posted benchmarks, although they are still substantial:

$ ./python -m timeit -s "a = set(range(100000)); sd = a.difference; b = set(range(1000))" "sd(b)"
- before: 5.56 msec per loop
- after: 3.18 msec per loop

$ ./python -m timeit -s "a = set(range(1000000)); sd = a.difference; b = set(range(10))" "sd(b)"
- before: 67.9 msec per loop
- after: 41.8 msec per loop

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Sat May 15 23:11:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:11:00 +0000
Subject: [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

[...]
test_capi
test test_capi failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'' != b'Fatal Python error: PyThreadState_Get: no current thread'

----------
components: Library (Lib), Tests
messages: 105824
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_capi failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8726>
_______________________________________

From report at bugs.python.org  Sat May 15 23:11:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:11:01 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

[...]
test_import
Warning -- sys.path was modified by test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_import.py", line 167, in test_module_with_large_stack
    exec('import ' + module)
  File "<string>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 320, in load_module
    code_object = self.get_code(module.__name__)
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 429, in get_code
    "object for {0!r}".format(fullname))
ImportError: no source or bytecode available to create code object for 'longlist'

----------
components: Library (Lib), Tests
messages: 105825
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_import failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Sat May 15 23:19:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:19:03 +0000
Subject: [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1273958343.53.0.844163235614.issue8726@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8726>
_______________________________________

From report at bugs.python.org  Sat May 15 23:25:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:25:46 +0000
Subject: [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1273958746.75.0.764612388834.issue8726@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It turns out that the test segfaults:

$ ./python -E -bb -c "import _testcapi; _testcapi.crash_no_current_thread()"
Erreur de segmentation (core dumped)


And here is the backtrace:

Program terminated with signal 11, Segmentation fault.
#0  PyErr_SetObject (exception=<type at remote 0x7970c0>, value='bork bork bork') at Python/errors.c:67
67	    exc_value = tstate->exc_value;
Missing debug package(s), you should install: glibc-debug-2.11.1-6mnb2.x86_64
(gdb) bt
#0  PyErr_SetObject (exception=<type at remote 0x7970c0>, value='bork bork bork') at Python/errors.c:67
#1  0x000000000046d0e7 in PyErr_SetString (exception=<type at remote 0x7970c0>, string=<value optimized out>)
    at Python/errors.c:125
#2  0x00007f6a0b31ec1f in crash_no_current_thread (self=<value optimized out>)
    at /home/antoine/py3k/__svn__/Modules/_testcapimodule.c:2014
#3  0x000000000045fb74 in call_function (f=Frame 0x184dcc0, for file <string>, line 1, in <module> (), 
    throwflag=<value optimized out>) at Python/ceval.c:3854
#4  PyEval_EvalFrameEx (f=Frame 0x184dcc0, for file <string>, line 1, in <module> (), throwflag=<value optimized out>)
    at Python/ceval.c:2670
#5  0x0000000000460715 in PyEval_EvalCodeEx (co=0x7f6a0d100d78, globals=<value optimized out>, 
    locals=<value optimized out>, args=0x0, argcount=<value optimized out>, kws=<value optimized out>, kwcount=0, defs=
    0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3307
#6  0x000000000046098b in PyEval_EvalCode (co=0x7970c0, globals='bork bork bork', locals=0x0) at Python/ceval.c:746
#7  0x0000000000482d6f in run_mod (command=<value optimized out>, flags=<value optimized out>) at Python/pythonrun.c:1716
#8  PyRun_StringFlags (command=<value optimized out>, flags=<value optimized out>) at Python/pythonrun.c:1650
#9  PyRun_SimpleStringFlags (command=<value optimized out>, flags=<value optimized out>) at Python/pythonrun.c:1226
#10 0x0000000000495a37 in Py_Main (argc=<value optimized out>, argv=<value optimized out>) at Modules/main.c:570
#11 0x0000000000414b95 in main (argc=5, argv=<value optimized out>) at ./Modules/python.c:50


That's probably because PyThreadState_GET() gets compiled to a simple lookup in non-debug mode, and doesn't trigger the fatal error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8726>
_______________________________________

From report at bugs.python.org  Sat May 15 23:35:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:35:11 +0000
Subject: [issue8665] "make pycremoval" fails
In-Reply-To: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>
Message-ID: <1273959311.79.0.249830603899.issue8665@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm trying a fix in r81209. If the buildbots don't complain I'll close the issue.

----------
assignee: barry -> pitrou
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8665>
_______________________________________

From report at bugs.python.org  Sat May 15 23:37:35 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 15 May 2010 21:37:35 +0000
Subject: [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1273959455.12.0.230027584495.issue8726@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Ah, darn. Any thoughts on what do to? Shall I make the test conditional on a pydebug build, or just remove it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8726>
_______________________________________

From report at bugs.python.org  Sat May 15 23:43:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:43:51 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1273959831.66.0.0991832321433.issue8727@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This can be narrowed down to the following test sequence:

$ ./python -E -m test.regrtest test_heapq test_import
test_heapq
test_import
Warning -- sys.path was modified by test_import
test test_import failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_import.py", line 167, in test_module_with_large_stack
    exec('import ' + module)
  File "<string>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 320, in load_module
    code_object = self.get_code(module.__name__)
  File "/home/antoine/py3k/__svn__/Lib/importlib/_bootstrap.py", line 429, in get_code
    "object for {0!r}".format(fullname))
ImportError: no source or bytecode available to create code object for 'longlist'


test_heapq involves test.support.import_fresh_module().

----------
nosy: +barry, brett.cannon, ncoghlan
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Sat May 15 23:45:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 May 2010 21:45:40 +0000
Subject: [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1273959940.01.0.68462719655.issue8726@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your test could call PyThreadState_Get() explicitly, before calling PyErr_SetString() (which should then never get executed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8726>
_______________________________________

From report at bugs.python.org  Sun May 16 00:01:22 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 22:01:22 +0000
Subject: [issue8728] 2.7 regression in httplib.py: AttributeError: 'NoneType'
	object has no attribute 'makefile'
In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>
Message-ID: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

On Linux, with Python 2.7 trunk (built on May 13th)

[...]
  File "/home/apy/as/pypm-trunk/eggs/httplib2-0.6.0-py2.7.egg/httplib2/__init__.py", line 1129, in request
    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
  File "/home/apy/as/pypm-trunk/eggs/httplib2-0.6.0-py2.7.egg/httplib2/__init__.py", line 912, in _request
    (response, content) = self._conn_request(conn, request_uri, method, body, headers, )
  File "/home/apy/as/pypm-trunk/eggs/httplib2-0.6.0-py2.7.egg/httplib2/__init__.py", line 871, in _conn_request
    response = conn.getresponse()
  File "/opt/ActivePython-2.7/lib/python2.7/httplib.py", line 1022, in getresponse
    response = self.response_class(*args, **kwds)
  File "/opt/ActivePython-2.7/lib/python2.7/httplib.py", line 340, in __init__
    self.fp = sock.makefile('rb', 0)
AttributeError: 'NoneType' object has no attribute 'makefile'

----------
components: Library (Lib)
messages: 105831
nosy: krisvale, srid
priority: normal
severity: normal
status: open
title: 2.7 regression in httplib.py: AttributeError: 'NoneType' object has no attribute 'makefile'
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8728>
_______________________________________

From report at bugs.python.org  Sun May 16 00:04:37 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 15 May 2010 22:04:37 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1273961077.68.0.339524294986.issue6645@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Looks like this has been fixed, at least on Python trunk (2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Sun May 16 00:08:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 15 May 2010 22:08:12 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The Mapping ABC's __eq__ method should return NotImplemented if the other type is not a Mapping, to give the other type a chance at the comparison.  Right now it simply returns false.

The comparison methods on the other ABCs in _abcoll.py already return NotImplemented if they don't recognize the other type.

----------
components: Library (Lib)
files: mapping.patch
keywords: patch
messages: 105833
nosy: stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: The Mapping ABC's __eq__ method should return NotImplemented if the other type is not a Mapping
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17355/mapping.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Sun May 16 00:20:43 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 15 May 2010 22:20:43 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1273962043.98.0.200561085939.issue8727@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

THe sys.path  modification warning is a red herring; the test simply was not cleaning up after itself properly. That little bit is fixed in r81214.

Don't know about the cause of the actual failure yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Sun May 16 00:48:14 2010
From: report at bugs.python.org (Nir Aides)
Date: Sat, 15 May 2010 22:48:14 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1273963694.2.0.00277790519903.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file17330/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 16 00:50:32 2010
From: report at bugs.python.org (Nir Aides)
Date: Sat, 15 May 2010 22:50:32 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1273963832.31.0.496727464468.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Updated bfs.patch to patch cleanly updated py3k branch. Use:
$ patch -p1 < bfs.patch

----------
Added file: http://bugs.python.org/file17356/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 16 00:50:50 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 15 May 2010 22:50:50 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1273963850.79.0.445186207133.issue8727@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I found the cause of the failure.

When Barry implemented PEP 3147, he made PyPycLoader.bytecode_path() operate as if the only possible bytecode file one would want is the __cached__ one. That obviously is not accurate in the face of source-less modules. So the test_import is failing because it is not even attempting a bytecode-only import.

What this means is that importlib needs to change its implementation of bytecode_path() to return the proper path based on whether the source exists. I will get to that hopefully this week. In the mean time I have flagged the test as an expected failure.

This also shows me even more that I need to redo the ABCs in importlib to essentially make bytecode an optimization that the ABC handles and that is not exposed to the importer implementer.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Sun May 16 00:52:58 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 15 May 2010 22:52:58 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1273963978.18.0.109906493936.issue8727@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Sun May 16 01:13:57 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 15 May 2010 23:13:57 +0000
Subject: [issue8712] Skip libpthread related test failures on OpenBSD
In-Reply-To: <1273846438.33.0.702131731388.issue8712@psf.upfronthosting.co.za>
Message-ID: <1273965237.23.0.983829872709.issue8712@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The gentoo-3.x buildbot also shows the threading problems again:

test test_subprocess failed -- Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/test_subprocess.py", line 770, in test_send_signal
    self.assertIn(b'KeyboardInterrupt', stderr)
AssertionError: b'KeyboardInterrupt' not found in b''


References:

[gentoo-3.x]
http://bugs.python.org/issue4970

[freebsd-6.4]
http://bugs.python.org/issue3864

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8712>
_______________________________________

From report at bugs.python.org  Sun May 16 01:44:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:44:53 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1273967093.81.0.827840280125.issue858809@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> skrah
nosy: +merwok, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Sun May 16 01:45:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:45:52 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1273967152.94.0.75239874901.issue858809@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Fixing Roundup form bug)

----------
assignee: skrah -> tarek
nosy:  -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Sun May 16 01:46:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:46:07 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1273967167.64.0.139612309473.issue858809@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Sun May 16 01:49:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:49:38 +0000
Subject: [issue3686] PKG-INFO file should differentiate between authors and
	maintainers
In-Reply-To: <1219739553.56.0.760950139316.issue3686@psf.upfronthosting.co.za>
Message-ID: <1273967378.44.0.517468338812.issue3686@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3686>
_______________________________________

From report at bugs.python.org  Sun May 16 01:53:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:53:40 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1273967620.48.0.511745295168.issue4007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note: Using find -delete avoids the extra process spawning for rm. However, if the -f option is really necessary, we?ll have to use rm.

Someone has an idea about the imperfect regex/glob pattern?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Sun May 16 01:55:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:55:26 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1273967726.62.0.605795690613.issue4508@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> sjoerd
components: +Distutils2 -Distutils
nosy: +merwok, sjoerd
versions: +Python 2.5, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Sun May 16 01:56:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:56:31 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1273967791.82.0.14428932029.issue4508@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Fixing damn HTML form changing select values, really sorry)

----------
assignee: sjoerd -> tarek
nosy:  -sjoerd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Sun May 16 01:56:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 May 2010 23:56:48 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
	output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1273967808.38.0.999509039896.issue4508@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Sun May 16 02:14:07 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 16 May 2010 00:14:07 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1273967620.48.0.511745295168.issue4007@psf.upfronthosting.co.za>
Message-ID: <19439.14535.515347.694801@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>> Note: Using find -delete avoids the extra process spawning for rm.

The -delete expression isn't universally available.  For example, it is not
present on Solaris.  Better just to stick with the reliable rm.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Sun May 16 03:13:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 01:13:09 +0000
Subject: [issue8725] Python3: use ASCII for the file system encoding on
	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1273972389.6.0.41398110147.issue8725@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 2:
 - #8715 has been commited: patch PyUnicode_EncodeFSDefault()
 - fix the documentation according the changes

----------
Added file: http://bugs.python.org/file17357/fsencoding_ascii-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8725>
_______________________________________

From report at bugs.python.org  Sun May 16 03:13:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 01:13:13 +0000
Subject: [issue8725] Python3: use ASCII for the file system encoding on
	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1273972393.61.0.436647224945.issue8725@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17353/fsencoding_ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8725>
_______________________________________

From report at bugs.python.org  Sun May 16 04:15:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 02:15:10 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1273976110.31.0.220970471211.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New patch fixing this issue:
 - os.get_exec_path() type now depends on the OS: str on Windows, bytes on Unix
 - os.get_exec_path(None) uses os.environ on Windows, os.environb on Unix
 - os.get_exec_path(env) uses 'PATH' or b'PATH' key, but raise a ValueError if both keys exist
 - add os.supports_bytes_environ flag (boolean)
 - os._execvpe() and subprocess._execute_child() canonicalize the program to bytes
 - test "not path.supports_unicode_filenames" to check if fsencode() should be defined and used (instead of testing name != "nt")

I'm not proud of the change on os.get_exec_path() result type, I'm not sure that it's the right thing to do. But at least, the patch works :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Sun May 16 04:22:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 02:22:49 +0000
Subject: [issue8640] subprocess: canonicalize env to bytes on Unix (Python3)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273976569.61.0.394545649593.issue8640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pitou> Why wouldn't you give byte variables in env too?

Ok, attached patch canonicalize env keys and values to bytes. If a variable is defined twice (str name, bytes name), a ValueError is raised.

The patch depends on #8513: it requires that os.get_exec_path() is patched to support b'PATH' key.

----------
dependencies: +subprocess: support bytes program name (POSIX)
keywords: +patch
title: subprocess: add envb argument to Popen constructor (Python3, POSIX only) -> subprocess: canonicalize env to bytes on Unix (Python3)
Added file: http://bugs.python.org/file17358/subprocess_canonalize_env.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Sun May 16 04:29:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 02:29:36 +0000
Subject: [issue8640] subprocess: canonicalize env to bytes on Unix (Python3)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1273976976.3.0.651022652911.issue8640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.1 accepts duplicate variables (str name, bytes name). It creates the two variables is a random order:

>>> subprocess.call(['env'], env={'xx': 'str', b'xx': 'bytes'})
xx=str
xx=bytes
0
>>> subprocess.call(['env'], env={'xxx': 'str', b'xxx': 'bytes'})
xxx=bytes
xxx=str
0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Sun May 16 04:36:21 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 May 2010 02:36:21 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1273977381.65.0.52506769234.issue8729@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

A test would be good.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Sun May 16 05:14:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 May 2010 03:14:03 +0000
Subject: [issue8728] 2.7 regression in httplib.py: AttributeError: 'NoneType'
	object has no attribute 'makefile'
In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>
Message-ID: <1273979643.81.0.305319592226.issue8728@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you provide a small code example that will reproduce the problem?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8728>
_______________________________________

From report at bugs.python.org  Sun May 16 06:42:26 2010
From: report at bugs.python.org (Heikki Toivonen)
Date: Sun, 16 May 2010 04:42:26 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1273984946.16.0.950102912578.issue8550@psf.upfronthosting.co.za>


Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:

Since SSLv2 is insecure, could you at least add a warning for that protocol? I think there was a separate issue for removing it altogether, but could a warning be added here?

The documentation should mention that verify_mode=CERT_REQUIRED is recommended for security.

There should probably be an example of using SSL context in the documentation.

I think you need to expose SSL_CTX_set_options(). Currently the code just sets all options, which means that the default protocol SSLv23 will accept SSLv2 which is insecure. Most people would want to probably do something like ctx.set_options(SSL_OP_ALL | SSL_OP_NO_SSLv2). Documentation should also mention that this is recommended for security. See man SSL_CTX_set_options.

Otherwise I could not see issues with the code, apart from the still #if 0'd out sections and commented out sections, which you are planning on doing something about, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Sun May 16 07:07:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 16 May 2010 05:07:00 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273977381.65.0.52506769234.issue8729@psf.upfronthosting.co.za>
Message-ID: <AANLkTikjVWAtGDkJ7gL53bEYRXRO5tWJM6ViNpGv3x-7@mail.gmail.com>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Will do, sometime this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Sun May 16 09:03:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 16 May 2010 07:03:06 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273893301.17.0.843509125759.issue8721@psf.upfronthosting.co.za>
Message-ID: <20100516070254.GA9515@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

FWIW, it should also be noted that RFC asserts square brackets to be
valid characters in the hostname portion only and that too when it is
a IPv6 url. 

In the example given, at the query portion, it should be quoted (or
percent-encoded)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Sun May 16 09:12:38 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 16 May 2010 07:12:38 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1273993958.49.0.753809288013.issue8633@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8633>
_______________________________________

From report at bugs.python.org  Sun May 16 10:45:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 16 May 2010 08:45:31 +0000
Subject: [issue8692] Use divide-and-conquer for faster factorials
In-Reply-To: <1273609381.14.0.711112369478.issue8692@psf.upfronthosting.co.za>
Message-ID: <1273999531.79.0.501678058423.issue8692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed in r81196.  Thanks, everyone!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8692>
_______________________________________

From report at bugs.python.org  Sun May 16 11:37:39 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 09:37:39 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1274002659.82.0.872740025995.issue8716@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've filed an issue for this in the Tcl/Tk tracker: <https://sourceforge.net/tracker/?func=detail&aid=3002320&group_id=10894&atid=110894>

(Assuming that this is the canonical tracker for the Tcl/Tk project, it was the first hit in google for 'tk bug tracker').

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sun May 16 11:40:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 09:40:08 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1274002808.57.0.374221606181.issue8716@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. Another way of testing, assuming you have two accounts: use 'su - otheraccount' to get a shell session as another user then try to start tk using:

import Tkinter
root = Tkinter.Tk()

This will currently crash the interpreter due to an uncaught Objective-C exception (as seen in msg105735)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sun May 16 12:18:29 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 10:18:29 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1274005109.07.0.992094724211.issue8716@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch is a first start at working around the crash. With this patch I can use Tk without a crash:

>>> import Tkinter
>>> Tkinter.Tk()
Sun May 16 12:11:08 Rivendell.local python.exe[55984] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
<Tkinter.Tk instance at 0x100592d88>
>>> 2010-05-16 12:11:08.771 python.exe[55984:903] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
Unexpected Objective-C exception in Tk
>>>

This isn't ideal though, especially because the patch requires that you build using an SDK or explicitly specify a deployment target (MACOSX_DEPLOYMENT_TARGET=10.5) during build.

Another reason to dislike this: the errors are swallowed instead of propagated to Python code.

I haven't checked yet if this patch allows you to run the tests without crashing.

----------
keywords: +patch
Added file: http://bugs.python.org/file17359/issue-8716.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sun May 16 12:21:50 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 10:21:50 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1274005310.59.0.283838819123.issue8716@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Something I forgot to mention: the patch introduces "_tkinter.m" to enable compiling the _tkinter extension as Objective-C code.  The compiler also supports passing "-x objective-c" to compile _tkinter.c in Objective-C mode, but this flag must be specified early on the GCC command-line and I haven't been able to trick distutils in passing the flags at the right place yet.

Just adding ['-x', 'objective-c'] to the extra_compile_args argument to Extension does not work: that appends the flags to the compiler command-line while the -x flag only works when it is before the name of the source file(s).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sun May 16 12:29:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 10:29:12 +0000
Subject: [issue5766] Mac/scripts/BuildApplet.py reset of sys.executable during
	install can cause it to use wrong modules
In-Reply-To: <1239840739.74.0.413438515887.issue5766@psf.upfronthosting.co.za>
Message-ID: <1274005752.62.0.0538470059233.issue5766@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5766>
_______________________________________

From report at bugs.python.org  Sun May 16 12:34:21 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 10:34:21 +0000
Subject: [issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1274006061.21.0.165528335765.issue8688@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

One way to fix this: is to always recreate MANIFEST when an explicit MANIFEST.in file exists, as in the attached patch.

(The patch is not perfect: I'd rename "template_newer" before committing)

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file17360/always-regen-manifest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8688>
_______________________________________

From report at bugs.python.org  Sun May 16 12:45:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 10:45:20 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1273984946.16.0.950102912578.issue8550@psf.upfronthosting.co.za>
Message-ID: <1274006705.3089.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since SSLv2 is insecure, could you at least add a warning for that
> protocol? I think there was a separate issue for removing it
> altogether, but could a warning be added here?

I think it should be a separate issue (since it also applies to the
legacy API). I agree it's reasonable to issue a warning. I don't think
we should remove it until OpenSSL itself does, though.

> The documentation should mention that verify_mode=CERT_REQUIRED is recommended for security.

I think we should recommend CERT_OPTIONAL. A server running with
CERT_REQUIRED would refuse clients without a client certificate, which
is probably not common practice for most servers.

(CERT_OPTIONAL is SSL_VERIFY_PEER, and
 CERT_REQUIRED is SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT.
The OpenSSL doc says there's no different between both when in client
mode)

> I think you need to expose SSL_CTX_set_options(). Currently the code
> just sets all options, which means that the default protocol SSLv23
> will accept SSLv2 which is insecure. Most people would want to
> probably do something like ctx.set_options(SSL_OP_ALL |
> SSL_OP_NO_SSLv2).

There is a separate issue for it (whose patch I will update to use the
new context API when it is committed):
http://bugs.python.org/issue4870
Do note that OpenSSL 1.0.0 disables SSLv2 by default when using SSLv23,
by the way.

> Otherwise I could not see issues with the code, apart from the still
> #if 0'd out sections and commented out sections, which you are
> planning on doing something about, right?

Yes, there's a bit of cleanup work remaining.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Sun May 16 12:55:58 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 16 May 2010 10:55:58 +0000
Subject: [issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1274007358.38.0.416617225586.issue8688@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The same problem occurs without a manifest template: you can have options or imports in setup.py that will change the MANIFEST file. 

For example : if setup() has:

  packages=['foo']

And if you add a subpackage "bar" in "foo" with some modules, with an existing MANIFEST, they won't be added.

IOW, the MANIFEST file should be recalculated *everytime*. I am going to remove all the "don't rebuilt MANIFEST" code in Distutils *and* Distutils2.

----------
components: +Distutils2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8688>
_______________________________________

From report at bugs.python.org  Sun May 16 12:56:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 16 May 2010 10:56:31 +0000
Subject: [issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1274007391.42.0.761789358835.issue8688@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8688>
_______________________________________

From report at bugs.python.org  Sun May 16 14:10:02 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:10:02 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011802.06.0.342192638924.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

As part of issue 8510 (update to autoconf2.65) configure script is modernized and most of  updates from patches attached to this issue now are in repository.

Starting from 16 may new patches will include in addition minimal updates of setup.py and Makefile.pre.in (moved from issue 3871) : 
- build modules with system python (from 3871).
- configure ctypes with same arguments as top configure (new)

----------
title: minimal cross-compilation support for configure -> cross-compilation support for python build
Added file: http://bugs.python.org/file17361/python-trunk-20100516-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:10:33 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:10:33 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1274011833.0.0.280164832754.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Common to all platforms part of patches lets call it  "build modules with system python"  is moved to issue 3754.

----------
Added file: http://bugs.python.org/file17362/python-trunk-20100516-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun May 16 14:10:47 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:10:47 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011847.1.0.701520929104.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file14539/python-trunk-20090722-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:10:55 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:10:55 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011855.21.0.20680163383.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15260/python-trunk-20091104-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:11:03 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:11:03 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011863.38.0.0545291264496.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15415/python-trunk-20091129-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:11:10 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:11:10 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011870.56.0.505740843327.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15464/python-trunk-20091206-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:11:15 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:11:15 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011875.7.0.383756003814.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15724/python-trunk-20100103-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:11:23 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:11:23 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1274011883.07.0.0191777846147.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file15987/python-trunk-20100124-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun May 16 14:20:24 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 16 May 2010 12:20:24 +0000
Subject: [issue8699] Equality and hashing for functools.partial
In-Reply-To: <1273676448.87.0.841686829268.issue8699@psf.upfronthosting.co.za>
Message-ID: <1274012424.5.0.199549290744.issue8699@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

In this new patch, __eq__ compares also the __dict__ of the two partial instances.

----------
Added file: http://bugs.python.org/file17363/partial_eq_hash_4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8699>
_______________________________________

From report at bugs.python.org  Sun May 16 14:21:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 12:21:57 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Output of test_distutils on a older SuSE Linux system:

FAILED (errors=1, skipped=5)
Traceback (most recent call last):
  File "../Lib/test/test_distutils.py", line 18, in <module>
    test_main()
  File "../Lib/test/test_distutils.py", line 13, in test_main
    test_support.run_unittest(distutils.tests.test_suite())
  File "/home/xsupport/rtest/python-trunk/Lib/test/test_support.py", line 1038, in run_unittest
    _run_suite(suite)
  File "/home/xsupport/rtest/python-trunk/Lib/test/test_support.py", line 1021, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/tests/test_archive_util.py", line 167, in test_compress_deprecated
    make_tarball(base_name, 'dist', compress='compress')
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/archive_util.py", line 116, in make_tarball
    spawn(cmd, dry_run=dry_run)
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/xsupport/rtest/python-trunk/Lib/distutils/spawn.py", line 141, in _spawn_posix
    (cmd[0], exit_status)
DistutilsExecError: command 'compress' failed with exit status 1


This system has a fake 'compress' command that only supports uncompress functionality:

$ compress --help
Usage: compress OPTION FILE
Dummy script for uncompressing legacy shar files.

with OPTION in:
      --help      display this help and exit
      --version   output version information and exit

  -d              uncompress

Use `gzip' for compressing files.

----------
assignee: tarek
components: Distutils
messages: 105862
nosy: ronaldoussoren, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Spurious test failure in distutils
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Sun May 16 14:29:21 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 16 May 2010 12:29:21 +0000
Subject: [issue8731] BeOS for 2.7 - add to unsupported
In-Reply-To: <1274012961.91.0.790344514824.issue8731@psf.upfronthosting.co.za>
Message-ID: <1274012961.91.0.790344514824.issue8731@psf.upfronthosting.co.za>


New submission from Roumen Petrov <bugtrack at roumenpetrov.info>:

PEP 11 describe BeOS support as : "Python 2.7 (edit configure to reenable)"

----------
components: Build
files: python-2.7-beos-unsupported.patch
keywords: patch
messages: 105863
nosy: rpetrov
priority: normal
severity: normal
status: open
title: BeOS for 2.7 - add to unsupported
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17364/python-2.7-beos-unsupported.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8731>
_______________________________________

From report at bugs.python.org  Sun May 16 14:35:13 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 16 May 2010 12:35:13 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274013313.05.0.00528055956567.issue8730@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ouch, what a bad practice... 

The compress feature is going away anyway.

Could you tell me what "compress --version" says ?

Maybe we can use that output to discard this fake command when looking for the compress program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Sun May 16 14:39:37 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 16 May 2010 12:39:37 +0000
Subject: [issue3686] PKG-INFO file should differentiate between authors and
	maintainers
In-Reply-To: <1219739553.56.0.760950139316.issue3686@psf.upfronthosting.co.za>
Message-ID: <1274013577.1.0.0722197249325.issue3686@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This is now defined in PEP 345 and implemented in Distutils2.

----------
components: +Distutils2 -Distutils
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3686>
_______________________________________

From report at bugs.python.org  Sun May 16 14:40:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 12:40:09 +0000
Subject: [issue8731] BeOS for 2.7 - add to unsupported
In-Reply-To: <1274012961.91.0.790344514824.issue8731@psf.upfronthosting.co.za>
Message-ID: <1274013609.69.0.748915482046.issue8731@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8731>
_______________________________________

From report at bugs.python.org  Sun May 16 14:41:45 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 12:41:45 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274013705.95.0.707771143846.issue8730@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

$ compress --version
compress - sharutils 4.2c

And yes, this is jucky behavior. Most systems shouldn't be affected by this because sharutils isn't used a lot these days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Sun May 16 16:13:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:13:06 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274019186.61.0.0554786188726.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17291/issue1285086_fast_quote.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:13:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:13:16 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274019196.13.0.450357955918.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17295/issue1285086_using_translate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:13:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:13:20 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274019200.09.0.0849971625266.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17298/issue1285086_using_rstrip.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:13:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:13:36 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274019216.59.0.261025104756.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17299/urllib_quote_speed_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:16:30 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 16 May 2010 14:16:30 +0000
Subject: [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1274019390.25.0.838979515547.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

New data point: in some contexts on Windows (not sure of the exact cause but I was dealing with multiple drives), even this workaround isn't enough.  I ended up having to do something like this (i.e. manually search the path) on win32:


    def full_executable_path(invoked, environ):

        if os.path.splitext(invoked)[1]:
            return invoked
        
        explicit_dir = os.path.dirname(invoked)

        if explicit_dir:
            path = [ explicit_dir ]
        else:
            path = environ.get('PATH').split(os.path.pathsep)

        extensions = environ.get(
            'PATHEXT',
            # Use *something* in case the environment variable is
            # empty.  These come from my machine's defaults
            '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
            ).split(os.path.pathsep)

        for dir in path:
            for ext in extensions:
                full_path = os.path.join(dir, invoked+ext)
                if os.path.exists( full_path ):
                    return full_path

        return invoked # Not found; invoking it will likely fail

    class Popen(subprocess.Popen):
        def __init__(
            self, args, bufsize=0, executable=None,
            stdin=None, stdout=None, stderr=None,
            preexec_fn=None, close_fds=False, shell=False, 
            cwd=None, env=None, 
            *args_, **kw):

            if executable is None and not shell:
                executable = full_executable_path(args[0], env or os.environ)

            super(Popen,self).__init__(
                args, bufsize, executable, stdin, stdout, stderr, 
                preexec_fn, close_fds, shell, cwd, env, *args_, **kw)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________

From report at bugs.python.org  Sun May 16 16:25:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:25:07 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274019907.17.0.204049143468.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Updated script for benchmarks (on 2.x and 3.x).
Inspired by the "Tools/iobench" script.

It benchmarks various quote/unquote implementations on 2.x and 3.x.

On 2.7 the fastest implementation is something like:

    def quote(s):
        if not s or not s.rstrip(safe):
            return s
        return ''.join(map(safe_get, s))


On 3.2 the fastest implementation uses list comprehension:

    def quote_from_bytes(s):
        if not s:
            return ''
        if not s.rstrip(safe):
            return s.decode()
        return ''.join([quoter(c) for c in s])


Note: the regexp implementation is slower in both cases.

----------
Added file: http://bugs.python.org/file17365/quotebench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:27:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:27:03 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274020023.41.0.568213844696.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Added file: http://bugs.python.org/file17366/issue1285086_using_rstrip_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:27:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 16 May 2010 14:27:36 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274020056.72.0.593169146219.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Proposed patches for quote and unquote on 2.7 and 3.2.

----------
Added file: http://bugs.python.org/file17367/issue1285086_using_rstrip_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sun May 16 16:47:11 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 16 May 2010 14:47:11 +0000
Subject: [issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>
Message-ID: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

According to the RFC, the server is allowed to send back any encoding it likes when no Accept-Encoding header is supplied, but all the examples I can find of urllib2.urlopen usage assume they're getting plain text back.  I think it would be better to inject an Accept-Encoding header when none is explicitly supplied so that nobody else trips over this issue.

See http://support.github.com/discussions/site/1510

----------
components: Library (Lib)
messages: 105870
nosy: dabrahams
priority: normal
severity: normal
status: open
title: Should urrllib2.urlopen send an Accept-Encoding header?
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8732>
_______________________________________

From report at bugs.python.org  Sun May 16 17:39:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 15:39:59 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1274024399.38.0.897417643258.issue8550@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch addressing Heikki's and Jean-Paul's review comments (including additional documentation and a test for capath).

----------
Added file: http://bugs.python.org/file17368/sslcontext4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Sun May 16 18:48:57 2010
From: report at bugs.python.org (alon horev)
Date: Sun, 16 May 2010 16:48:57 +0000
Subject: [issue8733] list type and UserList do not call super in __init__ and
	therefore, they cannot be parents in a multiple inheritence scheme
Message-ID: <1274028536.9.0.783549366424.issue8733@psf.upfronthosting.co.za>


Changes by alon horev <alonho at gmail.com>:


----------
components: Extension Modules
nosy: alonho
priority: normal
severity: normal
status: open
title: list type and UserList do not call super in __init__ and therefore, they cannot be parents in a multiple inheritence scheme
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8733>
_______________________________________

From report at bugs.python.org  Sun May 16 20:12:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 18:12:32 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1274033552.56.0.184461818399.issue4931@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Sun May 16 20:18:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 18:18:44 +0000
Subject: [issue808129] Change --changelog to accept files
Message-ID: <1274033924.35.0.0411419319037.issue808129@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808129>
_______________________________________

From report at bugs.python.org  Sun May 16 20:22:13 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 16 May 2010 18:22:13 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

In python trunk, _set_invalid_parameter_handler() has been dropped and replaced by custom checking functions, but in msvcrt.get_osfhandle() these checks aren't present, so providing a bad FD leads to a crash.

Here is the little fix + a test (added to test_fileio, because I can't find unit tests for the msvcrt builtin, and similar "bad fd" cases are treated there).

----------
components: IO
files: msvcrt_crash.patch
keywords: patch
messages: 105872
nosy: pakal
priority: normal
severity: normal
status: open
title: msvcrt get_osfhandle crash on bad FD
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file17369/msvcrt_crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8734>
_______________________________________

From report at bugs.python.org  Sun May 16 20:24:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 18:24:46 +0000
Subject: [issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>
Message-ID: <1274034286.25.0.122259612589.issue8732@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8732>
_______________________________________

From report at bugs.python.org  Sun May 16 20:28:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 18:28:13 +0000
Subject: [issue8523] shutil.rmtree and os.listdir cannot recover on error
	conditions
In-Reply-To: <1272135463.46.0.698266589767.issue8523@psf.upfronthosting.co.za>
Message-ID: <1274034493.02.0.205407554551.issue8523@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8523>
_______________________________________

From report at bugs.python.org  Sun May 16 20:28:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 18:28:28 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1274034508.56.0.484804852995.issue8550@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch in r81233. I'm going to watch the buildbots and close the issue if everything's fine.

----------
assignee:  -> pitrou
resolution:  -> accepted
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Sun May 16 20:28:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 18:28:32 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1274034512.66.0.309965678242.issue7969@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Sun May 16 21:11:22 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 16 May 2010 19:11:22 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1274037082.2.0.181880983347.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Added file: http://bugs.python.org/file17370/nir-ccbench-linux.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 16 21:16:36 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 16 May 2010 19:16:36 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1274037396.45.0.144969205351.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

A link to ccbench results comparing old GIL, old GIL with long check interval, new GIL and BFS:
http://bugs.python.org/file17370/nir-ccbench-linux.log

Summary:

Results for ccbench latency and bandwidth test run on Ubuntu Karmic 64bit, q9400 2.6GHz, all Python versions built with computed gotos optimization.

Old GIL:
Hi level of context switching and reduced performance. 
~90ms IO latency with pure Python CPU bound background threads and low IO bandwidth results.

Old GIL with sys.setcheckinterval(2500) as done by Zope:
Context switching level back to normal.
IO latency shoots through the roof. ~950ms (avg) is the maximum recordable value in this test since CPU load duration is 2sec.

New GIL:
The expected 5ms wait related IO latency and low IO bandwidth.

BFS patch:
Behaves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 16 21:23:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 19:23:07 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1274037787.73.0.910277447095.issue6916@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________

From report at bugs.python.org  Sun May 16 21:34:56 2010
From: report at bugs.python.org (John W. Shipman)
Date: Sun, 16 May 2010 19:34:56 +0000
Subject: [issue8735] optparse: parse_args(values=...) does not set up default
	values
In-Reply-To: <1274038496.46.0.600699975761.issue8735@psf.upfronthosting.co.za>
Message-ID: <1274038496.46.0.600699975761.issue8735@psf.upfronthosting.co.za>


New submission from John W. Shipman <john at nmt.edu>:

optparse's .parse_args() method has a 'values=...' keyword argument
that is documented as:

    'object to store option arguments in (default: a new instance of
    optparse.Values)'

There is no description of what types this argument may have.
I was writing a class to digest the command line, and my bright
idea was to request that .parse_args deposit the attribute
values right into 'self' in the class constructor.

This works only for arguments that were actually specified; it
stores no attribute value at all for missing options that have
associated default options.

Below is a small script that demonstrates this behavior.  It
accepts one '-t' option, with default value 'DEFAULT'.  Here
is the output when the option is specified, and when it is not:

$ bad -t foo
foo
$ bad
Traceback (most recent call last):
  File "bad", line 23, in <module>
    main()
  File "bad", line 13, in main
    print args.test
AttributeError: Args instance has no attribute 'test'

Here is the test script:

#!/usr/bin/env python
#================================================================
# bad:  Demonstrate defect in optparse.
#   I want optparse to honor the .parse_args(values=...)
#  argument to store the attributes directly in self in the
#  constructor.  It works only for options actually specified;
#  default values are not copied into self.
#----------------------------------------------------------------
import sys, optparse

def main():
    args = Args()
    print args.test

class Args:
    def __init__(self):
        parser = optparse.OptionParser()
        parser.add_option ( "-t", "--test", dest="test",
            type="string", default="DEFAULT" )
        discard, positionals = parser.parse_args(values=self)

if __name__ == "__main__":
    main()
--------------------------------------------------------------

----------
components: Library (Lib)
messages: 105875
nosy: john at nmt.edu
priority: normal
severity: normal
status: open
title: optparse: parse_args(values=...) does not set up default values
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8735>
_______________________________________

From report at bugs.python.org  Sun May 16 21:35:23 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 16 May 2010 19:35:23 +0000
Subject: [issue8716] test_tk fails on OS X if run from buildbot slave daemon
	-- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1274038523.35.0.463985033638.issue8716@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Tk has a different tracker than tcl itself, the upstream issue is now <https://sourceforge.net/tracker/?func=detail&aid=3002484&group_id=12997&atid=112997>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Sun May 16 21:36:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 19:36:28 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1274038588.64.0.567227369622.issue2211@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun May 16 22:23:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 16 May 2010 20:23:06 +0000
Subject: [issue8736] *= is undocumented for lists
Message-ID: <1274041386.78.0.769910739974.issue8736@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee: stutzbach
components: Documentation
keywords: easy
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: *= is undocumented for lists
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8736>
_______________________________________

From report at bugs.python.org  Sun May 16 22:25:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 20:25:17 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1274041517.48.0.876267528376.issue8550@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A couple of buildbot failures led to fixes in r81234 and r81235. Everything should be fine now.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8550>
_______________________________________

From report at bugs.python.org  Sun May 16 23:03:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 May 2010 21:03:32 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1274043812.63.0.413537351903.issue7946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 16 23:26:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 21:26:19 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1274045179.43.0.485140782654.issue8477@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited the fix on _ssl._test_decode_cert() as r81237 (py3k, blocked in 3.1: r81238). Issue #8550 got accepted and uses PyUnicode_FSConverter for the filenames (except _ssl._test_decode_cert() which is now fixed).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Sun May 16 23:31:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 21:31:24 +0000
Subject: [issue8737] ssl.RAND_add() should only accept bytes (not str)
In-Reply-To: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>
Message-ID: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PySSL_RAND_add() uses PyArg_ParseTuple(args, "s#d:RAND_add", ...) and so converts implicitly str to bytes using UTF-8. I would prefer that this function only accepts bytes: the user will have to encode str to bytes *explicitly*.

Attached patch replace s# format by y# format.

----------
components: Library (Lib)
files: ssl_rand_add_bytes.patch
keywords: patch
messages: 105879
nosy: haypo
priority: normal
severity: normal
status: open
title: ssl.RAND_add() should only accept bytes (not str)
versions: Python 3.2
Added file: http://bugs.python.org/file17371/ssl_rand_add_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8737>
_______________________________________

From report at bugs.python.org  Sun May 16 23:38:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 21:38:34 +0000
Subject: [issue8477] _ssl: support surrogates in filenames,
	and bytes/bytearray filenames
In-Reply-To: <1271806718.84.0.17803607621.issue8477@psf.upfronthosting.co.za>
Message-ID: <1274045914.1.0.0927120909228.issue8477@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I forgot to patch RAND_egd()! Fixed: r81239 (py3k, blocked in 3.1: r81240).

The whole ssl module should now be fully "str+surrogates/bytes filenames" compliant :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8477>
_______________________________________

From report at bugs.python.org  Sun May 16 23:39:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 16 May 2010 21:39:42 +0000
Subject: [issue8737] ssl.RAND_add() should only accept bytes (not str)
In-Reply-To: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>
Message-ID: <1274045982.74.0.381021645447.issue8737@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This function is here to add entropy to the random numbers generator.
the kind of data is not important, and no matter which encoding is used, this will not change the quality of the entropy.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8737>
_______________________________________

From report at bugs.python.org  Sun May 16 23:40:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 21:40:19 +0000
Subject: [issue8737] ssl.RAND_add() should only accept bytes (not str)
In-Reply-To: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>
Message-ID: <1274046019.48.0.040164452612.issue8737@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8737>
_______________________________________

From report at bugs.python.org  Sun May 16 23:46:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 21:46:37 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274046397.68.0.405569731218.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I forgot to add the new patch: subprocess_bytes_program-3.patch.

----------
Added file: http://bugs.python.org/file17372/subprocess_bytes_program-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 00:05:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:05:42 +0000
Subject: [issue8737] ssl.RAND_add() should only accept bytes (not str)
In-Reply-To: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>
Message-ID: <1274047542.82.0.658864940527.issue8737@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think Amaury is right. You could add a test that bytes are also accepted, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8737>
_______________________________________

From report at bugs.python.org  Mon May 17 00:07:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:07:42 +0000
Subject: [issue8665] "make pycremoval" fails
In-Reply-To: <1273348260.64.0.925523005722.issue8665@psf.upfronthosting.co.za>
Message-ID: <1274047662.26.0.727339740778.issue8665@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8665>
_______________________________________

From report at bugs.python.org  Mon May 17 00:09:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:09:19 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274047759.79.0.32359754478.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch, following checkin of the new SSL contexts. Options can be specified as an `options` property on SSL contexts.

----------
nosy: +exarkun, heikki
Added file: http://bugs.python.org/file17373/sslopts3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Mon May 17 00:16:14 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Sun, 16 May 2010 22:16:14 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1274048174.01.0.264862196389.issue8685@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

Antoine: Thanks for the updated benchmark results!  I should have done that myself earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Mon May 17 00:20:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:20:28 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274048428.7.0.898662425182.issue4870@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file17373/sslopts3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Mon May 17 00:20:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:20:39 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274048439.01.0.503162467762.issue4870@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file17374/sslopts3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Mon May 17 00:38:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 22:38:30 +0000
Subject: [issue8737] ssl.RAND_add() should only accept bytes (not str)
In-Reply-To: <1274045484.85.0.763677080971.issue8737@psf.upfronthosting.co.za>
Message-ID: <1274049510.79.0.35976061987.issue8737@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> the kind of data is not important, and no matter which encoding 
> is used, this will not change the quality of the entropy.

Ok, you are right :-)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8737>
_______________________________________

From report at bugs.python.org  Mon May 17 00:39:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:39:44 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274049584.94.0.136826989704.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch adds a couple of words about SSLv2 in the "security considerations" paragraph. Reviewing is welcome.

----------
Added file: http://bugs.python.org/file17375/sslopts3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Mon May 17 00:39:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 22:39:49 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274049589.75.0.881147002052.issue4870@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file17374/sslopts3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Mon May 17 01:14:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 23:14:56 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274051696.42.0.105161442793.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I asked on #python-dev about os.get_exec_path() result type. As expected, the answer was "It's a really bad idea".

So here is a new version of my patch. Summary of the patch version 4:
 - subprocess.Popen() and os._execvpe() support bytes program name
 - os.get_exec_path() now supports b'PATH' key and bytes value
 - add os.supports_bytes_environ flag: "True if the native OS type of the environment is bytes (eg. False on Windows)"

Changes since the version 3:
 - document the new os.supports_bytes_environ flag
 - os.get_exec_path() result type is always str (decode bytes to str using sys.getfilesystemencoding() + surrogateescape)
 - path.supports_unicode_filenames is False on Windows 9x but Windows 9x native type is unicode and so fsencode() should not be defined on this OS: revert the fsencode() test (if not path.supports_unicode_filenames => if name != 'nt')

----------
Added file: http://bugs.python.org/file17376/subprocess_bytes_program-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 01:15:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 16 May 2010 23:15:13 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274051713.81.0.0903540869547.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17372/subprocess_bytes_program-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 01:28:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 May 2010 23:28:08 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274052488.58.0.494185599694.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It turns out SSL_CTX_clear_options() is not available before OpenSSL 0.9.8m. I adapted my patch to raise a ValueError when trying to clear options on older versions of OpenSSL. Setting additional options still works, though.

----------
Added file: http://bugs.python.org/file17377/sslopts4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Mon May 17 02:19:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:19:42 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055582.13.0.549567054355.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I forgot to update test_os: patch version 5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:19:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:19:57 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055597.85.0.359542053947.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17378/subprocess_bytes_program-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:20:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:20:02 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055602.98.0.496682122471.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17376/subprocess_bytes_program-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:21:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:21:00 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055660.39.0.68313684208.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17240/issue8513_partA.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:21:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:21:03 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055663.13.0.350216590842.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17261/issue8513_partA-fsencode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:21:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:21:06 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055666.16.0.765449989222.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17378/subprocess_bytes_program-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:21:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:21:12 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274055672.78.0.872230883698.issue8513@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file17379/subprocess_bytes_program-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:31:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:31:41 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274056301.3.0.572600700055.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, everything is ready for this issue: os.environb and os.fsencode() are commited, and test_os is prepared to test os._execvpe() change. I'm just waiting for a review.

Execpt the change on os.get_exec_path(), the patch is now simple.

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Mon May 17 02:44:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:44:30 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274057070.75.0.533719522395.issue6697@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16442/object_pyunicode_asstring-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon May 17 02:44:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:44:49 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274057089.84.0.872566505903.issue6697@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16502/unicode_fromformat_U.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon May 17 02:45:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:45:31 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274057131.3.0.476320702191.issue6697@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16443/ssl_rand_egd_unicode-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon May 17 02:47:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 00:47:05 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274057225.92.0.604565080067.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed ssl.RAND_egd() in r81239 (issue #8477).

Remove the other commited patches to see quickly which patches remain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon May 17 03:15:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 01:15:02 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274058902.89.0.336522423957.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pymain.patch commited as r81250. Wait for the buildbot before backporting it to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon May 17 03:15:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 01:15:41 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274058941.8.0.865336926303.issue6697@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file14730/pymain.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon May 17 10:04:44 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 17 May 2010 08:04:44 +0000
Subject: [issue8736] *= is undocumented for lists
In-Reply-To: <1274083484.9.0.313852961922.issue8736@psf.upfronthosting.co.za>
Message-ID: <1274083484.9.0.313852961922.issue8736@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

Does *= need document? I think the documentation of * for all sequence type can already cover the *= usage.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8736>
_______________________________________

From report at bugs.python.org  Mon May 17 10:58:29 2010
From: report at bugs.python.org (Sagiv Malihi)
Date: Mon, 17 May 2010 08:58:29 +0000
Subject: [issue8733] list type and UserList do not call super in __init__ and
	therefore, they cannot be parents in a multiple inheritence scheme
Message-ID: <1274086709.3.0.0183737074318.issue8733@psf.upfronthosting.co.za>


Changes by Sagiv Malihi <sagivmalihi at gmail.com>:


----------
nosy: +Sagiv.Malihi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8733>
_______________________________________

From report at bugs.python.org  Mon May 17 11:45:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 09:45:06 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274089506.75.0.48910279625.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Does my fix this #8533 fixes this issue or not? I guess yes, but I would prefer a confirmation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Mon May 17 12:45:20 2010
From: report at bugs.python.org (=?utf-8?q?Alberto_Planas_Dom=C3=ADnguez?=)
Date: Mon, 17 May 2010 10:45:20 +0000
Subject: [issue8738] cPickle dumps(tuple) != dumps(loads(dumps(tuple)))
In-Reply-To: <1274093120.19.0.592599712369.issue8738@psf.upfronthosting.co.za>
Message-ID: <1274093120.19.0.592599712369.issue8738@psf.upfronthosting.co.za>


New submission from Alberto Planas Dom?nguez <aplanas at gmail.com>:

Sometimes, when I use cPickle to serialize tuples of strings, I get different dumps() result for the same tuple:

import cPickle
t = ('<s>', 'JOHN')
s1 = cPickle.dumps(t)
s2 = cPickle.dumps(cPickle.loads(cPickle.dumps(t)))
assert s1 == s2     # AssertionError

With cPickle doesn't matter what protocol use por dumps(). The assertion is Ok if I use the pickle module instead of cPickle.

This means that I can't use a serialized object as a key in a map/dict object.

----------
messages: 105896
nosy: Alberto.Planas.Dom?nguez
priority: normal
severity: normal
status: open
title: cPickle dumps(tuple) != dumps(loads(dumps(tuple)))
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8738>
_______________________________________

From report at bugs.python.org  Mon May 17 12:49:21 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 17 May 2010 10:49:21 +0000
Subject: [issue8688] distutils sdist is too laze w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1274093361.73.0.408800796251.issue8688@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r81255, r81256 (2.6), r81258 (py3), r81260 (3.1)

Thanks Ronald

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8688>
_______________________________________

From report at bugs.python.org  Mon May 17 12:50:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 10:50:32 +0000
Subject: [issue8738] cPickle dumps(tuple) != dumps(loads(dumps(tuple)))
In-Reply-To: <1274093120.19.0.592599712369.issue8738@psf.upfronthosting.co.za>
Message-ID: <1274093432.37.0.945614031839.issue8738@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think you can expect serialized results to always be equal. It can depend on specifics of the internal algorithm, such as optimizations or dict iteration order.

----------
nosy: +alexandre.vassalotti, pitrou
priority: normal -> low
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8738>
_______________________________________

From report at bugs.python.org  Mon May 17 13:13:24 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 17 May 2010 11:13:24 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274094804.24.0.0998570286177.issue8730@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

So do you know if this is specific to all sharutils versions ? 

I could read the version and raise a specific error in that case.
*or* just not fix this bug and fix the test so it's permissive in this very particular case (by looking at the compression version)

What do you think ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Mon May 17 13:51:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 11:51:01 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274097061.34.0.735074602764.issue8730@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just skip the test, IMO.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Mon May 17 14:35:57 2010
From: report at bugs.python.org (Victor Godoy Poluceno)
Date: Mon, 17 May 2010 12:35:57 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1274099757.36.0.45331642548.issue7946@psf.upfronthosting.co.za>


Changes by Victor Godoy Poluceno <victorpoluceno at gmail.com>:


----------
nosy: +victorpoluceno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon May 17 15:23:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 17 May 2010 13:23:05 +0000
Subject: [issue8736] *= is undocumented for lists
In-Reply-To: <1274083484.9.0.313852961922.issue8736@psf.upfronthosting.co.za>
Message-ID: <1274102585.04.0.259104456845.issue8736@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Good point, since I see now that *= (and +=) also works on immutable sequence types (though does something subtly different).  I always forget that.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8736>
_______________________________________

From report at bugs.python.org  Mon May 17 15:34:09 2010
From: report at bugs.python.org (Alberto Trevino)
Date: Mon, 17 May 2010 13:34:09 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>


New submission from Alberto Trevino <alberto at byu.edu>:

This patch updates smtpd.py to be more RFC 5321 compliant.  It contains:

 - EHLO support
 - Implement DATA size limit (32 MiB by default)
 - 8-bit mime extension plumbing (doesn't do anything, but accepts and
   records command)
 - Basic VRFY support
 - Basic HELP support
 - A few improvements to messages (more in line with RFC 5321 examples)
 - Misc. documentation updates

The patch is specific to Python 3.1.  I have not tried to backport the changes to 2.x.  If possible, I would like the patch to be considered for inclusion to 3.2.

----------
components: Library (Lib)
files: smtpd.py-0.2-rfc5321-enhancements.diff
keywords: patch
messages: 105902
nosy: alfmel, barry
priority: normal
severity: normal
status: open
title: Update to smtpd.py to RFC 5321
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17380/smtpd.py-0.2-rfc5321-enhancements.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon May 17 15:38:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 17 May 2010 13:38:56 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274103536.66.0.0353446632141.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Committed in r81265 for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Mon May 17 15:45:51 2010
From: report at bugs.python.org (Christophe Combelles)
Date: Mon, 17 May 2010 13:45:51 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>


New submission from Christophe Combelles <ccomb at free.fr>:

This leads to a maximum recursion depth error:

$ python3.1
>>> import sys, pdb
>>> sys.setfilesystemencoding('iso8859-7')
>>> pdb.set_trace()

I'm on ubuntu 10.04 x86_64, with LANG=fr_FR.utf8

----------
components: None
messages: 105904
nosy: ccomb
priority: normal
severity: normal
status: open
title: infinite recursion with setfilesystemencoding and pdb
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Mon May 17 16:06:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 May 2010 14:06:37 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274105197.99.0.780052906274.issue8739@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon May 17 16:42:39 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 17 May 2010 14:42:39 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274107359.69.0.0583051551138.issue8739@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon May 17 16:47:14 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 17 May 2010 14:47:14 +0000
Subject: [issue2456] Make sysmodule.c compatible with Bazaar
In-Reply-To: <1206197607.7.0.946463718632.issue2456@psf.upfronthosting.co.za>
Message-ID: <1274107634.96.0.91762117144.issue2456@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2456>
_______________________________________

From report at bugs.python.org  Mon May 17 16:49:35 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 17 May 2010 14:49:35 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1274107775.3.0.550591297145.issue8727@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I cannot reproduce this on Ubuntu 10.04 with current py3k (r81268), even using the boiled down example given by Antoine.  What platform are you on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Mon May 17 17:00:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 17 May 2010 15:00:31 +0000
Subject: [issue1800] ctypes callback fails when called in Python with array
	argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1274108431.8.0.752684659172.issue1800@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky
stage:  -> unit test needed
versions: +Python 3.2, Python 3.3 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
_______________________________________

From report at bugs.python.org  Mon May 17 17:05:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 17 May 2010 15:05:06 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274108706.38.0.208284896291.issue8740@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Next release should fix it: 3.1.3
(Tested on 3.1 branch)

----------
nosy: +flox, haypo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> sys.setfilesystemencoding("xxx"); open("a") => stack overflow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Mon May 17 17:05:44 2010
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Mon, 17 May 2010 15:05:44 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274108744.62.0.74019428323.issue3051@psf.upfronthosting.co.za>


Maciek Fijalkowski <fijal at genesilico.pl> added the comment:

Hello.

I would like to complain. It was decided at some point some time ago that both pure-python and C version should run against the same test suite and should not have any differencies. The reasoning behind it is that other python implementations might choose to use pure-python version and we should avoid surprises with random code crashing in obscure ways. Please don't divert deliberately those sources.

Cheers,
fijal

----------
nosy: +fijal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Mon May 17 17:07:28 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 17 May 2010 15:07:28 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274108848.36.0.21955083.issue3051@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at twistedmatrix.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Mon May 17 17:09:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 May 2010 15:09:03 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1274108943.18.0.303594394206.issue8734@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree with the fix.
However the patch should test for "sys.platform == 'win32'" before importing msvcrt.
And there is an extra space on another line.

----------
nosy: +amaury.forgeotdarc
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8734>
_______________________________________

From report at bugs.python.org  Mon May 17 17:09:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 May 2010 15:09:22 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1274108962.46.0.774034600309.issue8685@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will look at this when I get back to the U.S.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Mon May 17 17:13:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 15:13:04 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274109184.33.0.316822005885.issue8740@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What is the problem?

$ python3.1
Python 3.1.2 (r312:79147, Apr 21 2010, 23:52:07) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, pdb; sys.setfilesystemencoding('iso8859-7'); pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) 

Where is the infinite loop?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Mon May 17 17:18:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 15:18:35 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274109515.81.0.718926063159.issue8740@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The file system encoding should not be modifiable. Call sys.setfilesystemencoding() breaks Python, eg. module filenames are not reencoded. See also #8611.

sys.setfilesystemencoding() is as danregeous as sys.setdefaultencoding() because it changes too much things in Python.

If you would like to decode a filename with an encoding different than sys.setfilesystemencoding(): use the bytes type. Eg. os.listdir(b'.') gives you bytes filenames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Mon May 17 17:19:42 2010
From: report at bugs.python.org (Christophe Combelles)
Date: Mon, 17 May 2010 15:19:42 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274109582.81.0.795561146495.issue8740@psf.upfronthosting.co.za>


Christophe Combelles <ccomb at free.fr> added the comment:

Traceback (most recent call last):
  File "/usr/lib/python3.1/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/usr/lib/python3.1/encodings/__init__.py", line 98, in search_function
    level=0)
(...)
  File "/usr/lib/python3.1/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/usr/lib/python3.1/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/usr/lib/python3.1/encodings/__init__.py", line 83, in search_function
    norm_encoding = normalize_encoding(encoding)
  File "/usr/lib/python3.1/encodings/__init__.py", line 55, in normalize_encoding
    if isinstance(encoding, bytes):
RuntimeError: maximum recursion depth exceeded while calling a Python object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Mon May 17 17:23:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 May 2010 15:23:21 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274109801.66.0.655654682123.issue8740@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, flox closed the issue: it's a duplicate of #8226. The bug was fixed in Python 3.1.2 by myself (r79394).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Mon May 17 17:26:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 17 May 2010 15:26:05 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1274109965.86.0.939731812977.issue8730@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'd also skip the test, this is not a bug in Python but a broken compress executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Mon May 17 19:00:04 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 17 May 2010 17:00:04 +0000
Subject: [issue8726] test_capi failure
In-Reply-To: <1273957860.46.0.411830579262.issue8726@psf.upfronthosting.co.za>
Message-ID: <1274115604.43.0.668201170092.issue8726@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

Fixed in r81269. Sorry about that.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8726>
_______________________________________

From report at bugs.python.org  Mon May 17 19:00:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 17 May 2010 17:00:50 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274115650.11.0.556375109722.issue1285086@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


Removed file: http://bugs.python.org/file17366/issue1285086_using_rstrip_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Mon May 17 19:12:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 17 May 2010 17:12:51 +0000
Subject: [issue1800] ctypes callback fails when called in Python with array
	argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1274116371.04.0.0894986903121.issue1800@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch fixes the issue, but feels a little bit like a band-aid. I think making array arguments "decay" into pointers is the right solution, but I am not sure this should be done when prototype is created or when it is called.  If python level solution is accepted, a better way to detect an array type should probably be found.

----------
keywords: +patch
Added file: http://bugs.python.org/file17381/issue1800.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
_______________________________________

From report at bugs.python.org  Mon May 17 19:13:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 17 May 2010 17:13:38 +0000
Subject: [issue1800] ctypes callback fails when called in Python with array
	argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1274116418.7.0.800149167421.issue1800@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +needs review
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
_______________________________________

From report at bugs.python.org  Mon May 17 19:16:17 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 17 May 2010 17:16:17 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1274116577.52.0.259635768021.issue8734@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

My bad, here is a better patch...

----------
Added file: http://bugs.python.org/file17382/msvcrt_crash2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8734>
_______________________________________

From report at bugs.python.org  Mon May 17 19:16:21 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 17 May 2010 17:16:21 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1274116582.0.0.051688091158.issue8734@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file17369/msvcrt_crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8734>
_______________________________________

From report at bugs.python.org  Mon May 17 19:19:40 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 May 2010 17:19:40 +0000
Subject: [issue8734] msvcrt get_osfhandle crash on bad FD
In-Reply-To: <1274034133.01.0.249446827178.issue8734@psf.upfronthosting.co.za>
Message-ID: <1274116780.21.0.758132570469.issue8734@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The second patch looks good to me.

----------
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8734>
_______________________________________

From report at bugs.python.org  Mon May 17 19:37:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 17 May 2010 17:37:32 +0000
Subject: [issue1285086] urllib.quote is too slow
In-Reply-To: <1274103536.66.0.0353446632141.issue1285086@psf.upfronthosting.co.za>
Message-ID: <20100517173140.GA17832@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Mon, May 17, 2010 at 01:38:57PM +0000, Florent Xicluna wrote:
> Committed in r81265 for 2.7.

Thanks. That was interesting. Without resorting to any drastic changes like
use of regex, interesting speed-up seems to have been achieved by
using rsplit and map.

In py3k, I think its 'okay' to go for rsplit, defaultdict and map
which will be similar to py2k version. I saw that map vs list
comprehension did not have much differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Mon May 17 19:40:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 17 May 2010 17:40:17 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274118017.39.0.223058871426.issue1285086@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee: orsenthil -> flox
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Mon May 17 19:45:45 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 17 May 2010 17:45:45 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Repro steps:

Download http://appropriatesoftware.net/provide/docs/eternity-0.13.tar.gz (via 'eternity' module in PyPI) and look at the following command line session:

C:\Temp\tfbug>python27 -c "import tarfile as T; T.open('eternity-0.13.tar.gz').extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "C:\Python27\lib\tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "C:\Python27\lib\tarfile.py", line 2168, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "C:\Python27\lib\tarfile.py", line 2260, in makelink
    raise IOError("link could not be created")
IOError: link could not be created

C:\Temp\tfbug>python26 -c "import tarfile as T; T.open('eternity-0.13.tar.gz').extractall()"

C:\Temp\tfbug>dir eternity-0.13
 Volume in drive C has no label.
 Volume Serial Number is 1877-E6BA

 Directory of C:\Temp\tfbug\eternity-0.13

10/14/2008  06:08 PM    <DIR>          .
10/14/2008  06:08 PM    <DIR>          ..
09/05/2008  01:31 PM               115 AUTHORS
10/14/2008  06:08 PM    <DIR>          bin
09/05/2008  01:31 PM                 0 CHANGES
09/05/2008  01:31 PM            17,998 COPYING
10/14/2008  06:08 PM    <DIR>          etc
09/05/2008  01:31 PM               447 INSTALL
09/11/2008  06:06 PM               231 MANIFEST.in
10/14/2008  06:08 PM               802 PKG-INFO
09/05/2008  01:31 PM               516 README
09/10/2008  04:10 PM             2,948 setup.py
10/14/2008  06:08 PM    <DIR>          src
               8 File(s)         23,057 bytes
               5 Dir(s)   3,493,781,504 bytes free

C:\Temp\tfbug>

----------
components: Library (Lib), Windows
messages: 105920
nosy: lars.gustaebel, srid
priority: normal
severity: normal
status: open
title: 2.7 regression in tarfile: IOError: link could not be created
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Mon May 17 19:46:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 17 May 2010 17:46:05 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1274118365.04.0.914170678763.issue1285086@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Committed to 3.2 in r81271, after some additional tuning.

Btw, I kept list comprehension in 3.2, because it is faster for small strings (even if the gain is ~10%).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Mon May 17 19:54:18 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 17 May 2010 17:54:18 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1274118858.19.0.209048052904.issue6054@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Apparently this fix introduced a regression. See issue8741

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From report at bugs.python.org  Mon May 17 19:59:02 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Mon, 17 May 2010 17:59:02 +0000
Subject: [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

The link:
http://www.cs.princeton.edu/~danwang/Papers/dsl97/dsl97-abstract.html
in the file Parser/asdl.py seems to be broken. When I tried to open it I got a page with: "Sorry, the page you requested couldn't be found". It seems to me that this is a permanent issue and therefore the link should be removed as there is another link, that works.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 105923
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: broken asdl link in Parser/asdl.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8742>
_______________________________________

From report at bugs.python.org  Mon May 17 20:01:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 18:01:11 +0000
Subject: [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274119271.07.0.680472179034.issue8742@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8742>
_______________________________________

From report at bugs.python.org  Mon May 17 20:04:58 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 17 May 2010 18:04:58 +0000
Subject: [issue8633] tarfile doesn't support undecodable filename in PAX format
In-Reply-To: <1273097691.15.0.651636064492.issue8633@psf.upfronthosting.co.za>
Message-ID: <1274119498.51.0.497375888195.issue8633@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I added support for the hdrcharset method and a workaround for the GNU tar bug, see r81273.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8633>
_______________________________________

From report at bugs.python.org  Mon May 17 20:07:11 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 17 May 2010 18:07:11 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274119631.2.0.633921152242.issue8741@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

The actual exception caught (before it was ignored and a generic IOError was thrown) was this:

  File "C:\Python27\lib\tarfile.py", line 2168, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "C:\Python27\lib\tarfile.py", line 2258, in makelink
    shutil.copy2(linkpath, targetpath)
  File "C:\Python27\lib\shutil.py", line 127, in copy2
    copyfile(src, dst)
  File "C:\Python27\lib\shutil.py", line 81, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 'eternity-0.13\\src\\eternity\\django\\templates\\eui\\concerns\\..\\registry\\delet
e.html'

The specified file actually does not exist. Perhaps, in the middle of the extraction process, it was not created *yet*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Mon May 17 20:09:18 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 17 May 2010 18:09:18 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274119758.72.0.104581032047.issue8741@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Aside: why is the original exception ignored, and instead a generic IOError is thrown? Why not use one of the exceptions inheriting `TarError`, so that application code can reliably catch these errors?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Mon May 17 20:16:56 2010
From: report at bugs.python.org (trambalda)
Date: Mon, 17 May 2010 18:16:56 +0000
Subject: [issue7981] False failure with doctest NORMALIZE_WHITESPACE in 3.1.1
In-Reply-To: <1266843664.38.0.930233999383.issue7981@psf.upfronthosting.co.za>
Message-ID: <1274120216.33.0.0936516783958.issue7981@psf.upfronthosting.co.za>


trambalda <trambalda at gmail.com> added the comment:

Same problem in 2.6.4 r264:75708 and 3.1 r31:73574

----------
nosy: +trambalda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7981>
_______________________________________

From report at bugs.python.org  Mon May 17 20:38:52 2010
From: report at bugs.python.org (trambalda)
Date: Mon, 17 May 2010 18:38:52 +0000
Subject: [issue7981] False failure with doctest NORMALIZE_WHITESPACE in 3.1.1
In-Reply-To: <1266843664.38.0.930233999383.issue7981@psf.upfronthosting.co.za>
Message-ID: <1274121532.14.0.530830517061.issue7981@psf.upfronthosting.co.za>


trambalda <trambalda at gmail.com> added the comment:

but with print() it works:

    print("This text\n contains weird     spacing.")
    # doctest: +NORMALIZE_WHITESPACE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7981>
_______________________________________

From report at bugs.python.org  Mon May 17 20:50:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 17 May 2010 18:50:46 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The set() operators (__or__, __and__, __sub__, __xor__, and their in-place counterparts) require that the parameter also be an instance of set().

They're documented that way:  "This precludes error-prone constructions like set('abc') &  'cbs' in favor of the more readable set('abc').intersection('cbs')."

However, an unintended consequence of this behavior is that they don't inter-operate with user-created types that derive from collections.Set.

That leads to oddities like this:

MySimpleSet() | set()  # This works
set() | MySimpleSet()  # Raises TypeError

(MySimpleSet is a minimal class derived from collections.Set for illustrative purposes -- set attached file)

collections.Set's operators accept any iterable.

I'm not 100% certain what the correct behavior should be.  Perhaps set's operators should be a bit more liberal and accept any collections.Set instance, while collections.Set's operators should be a bit more conservative.  Perhaps not.  It's a little subjective.

It seems to me that at minimum set() and collections.Set() should inter-operate and have the same behavior.

----------
components: Interpreter Core
files: set-vs-set.py
messages: 105929
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: set() operators don't work with collections.Set instances
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17383/set-vs-set.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Mon May 17 21:01:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 17 May 2010 19:01:20 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1274122880.23.0.0809351792043.issue8743@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I should add:

I discovered the inconsistency while working on my sortedset class, which provides the same interface as set() but is also indexable like a list (e.g., S[0] always returns the minimum element, S[-1] returns the maximum element, etc.).

sortedset derives from collections.MutableSet, but it's challenging to precisely emulate set() when collections.MutableSet and set() don't work the same way. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Mon May 17 21:10:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 17 May 2010 19:10:18 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1274123418.51.0.248164062046.issue2521@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Antoine, do you have a suggestion for someone with with better knowledge of ABCs to do the final review, so that I may very politely pester them? ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Mon May 17 21:11:47 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 17 May 2010 19:11:47 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1274123507.0.0.898386838929.issue7079@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Is there anything more I can do to help get this crash-fix committed before 2.7 rc1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Mon May 17 22:01:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 20:01:31 +0000
Subject: [issue7079] file_close() ignores return value of close_the_file
In-Reply-To: <1254949845.61.0.606264060323.issue7079@psf.upfronthosting.co.za>
Message-ID: <1274126491.76.0.729713824025.issue7079@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, I had just forgotten. The patch has been committed in r81275 (trunk) and r81277 (2.6). Thank you:

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7079>
_______________________________________

From report at bugs.python.org  Mon May 17 22:07:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 20:07:43 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1274126863.68.0.126933679293.issue2521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, do you have a suggestion for someone with with better 
> knowledge of ABCs to do the final review, so that I may very politely 
> pester them? ;-)

I guess Benjamin could.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Mon May 17 22:13:05 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 17 May 2010 20:13:05 +0000
Subject: [issue6583] 2to3 fails to fix test.test_support
In-Reply-To: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
Message-ID: <1274127185.03.0.733915656547.issue6583@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Sorry to reraise an old issue, but the documentation of "test" module is deceiving on that one : "The test.test_support module has been renamed to test.support in Python 3.0. The 2to3 tool will automatically adapt imports when converting your sources to 3.0.".

I lost quite some time on this one...

----------
nosy: +pakal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6583>
_______________________________________

From report at bugs.python.org  Mon May 17 22:18:28 2010
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 17 May 2010 20:18:28 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1274127508.48.0.499649543676.issue8713@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

+1 for this issue; I've also wished for this feature in the past.

----------
nosy: +cool-RR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Mon May 17 22:30:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 17 May 2010 20:30:19 +0000
Subject: [issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>
Message-ID: <20100517203007.GA27020@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

HTTP Ref says that Server can send any encoding, if client does not
specify Accept-Encoding header. But if 'identity' is one of the
encoding that server recognizes (?), then it should send it as
identity, which indicates untransformed content.

I also see in the httplib that Accept-Encoding = 'identity' is added in the
request level to the headers. I shall see what is missing here, if it
is not being sent for all requests.

BTW, I could not figure out the problem you are facing from the url
mentioned. I specifically do not see any interleaving gzip and no-gzip
request behaviours at different points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8732>
_______________________________________

From report at bugs.python.org  Mon May 17 23:12:25 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 May 2010 21:12:25 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274130745.73.0.511398745991.issue8739@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Some comments:

-# This file implements the minimal SMTP protocol as defined in RFC 821.  It
+# This file implements the minimal SMTP protocol as defined in RFC 5321.  It

Is RFC 5321 completely implemented? Otherwise I would turn this in "as defined in RFC 821 and part of RFC 5321".

> - Implement DATA size limit (32 MiB by default)

I couldn't find any reference to this in RFC 5321. Is it recommended somewhere else maybe?
Also, issue 2518 and issue 1745035 are somewhat related with this specific problem.

> +        ## TODO: implement command help

Since you implemented HELP command in the first place it would be good to do it completely (I guess this means HELP should be able to accept arguments, as in FTP protocol).


Too bad smtpd currently lacks a test suite.
Before going any further with this issue I would recommend to write tests first.
I have a patch for adding a basic test suite for smtpd module I hope I'll be able to submit within this week.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Mon May 17 23:14:20 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 17 May 2010 21:14:20 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1274130859.92.0.904521016336.issue8727@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Brett marked it as an expected failure in r81219.

Probably should have mentioned that here at the time though...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Mon May 17 23:20:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 21:20:57 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274131257.15.0.419392642831.issue8729@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Mon May 17 23:23:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 21:23:37 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1274131417.68.0.60784087856.issue2226@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +stutzbach
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Mon May 17 23:25:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 21:25:26 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1274131526.85.0.305869779968.issue3362@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +janssen, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Mon May 17 23:38:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 21:38:32 +0000
Subject: [issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except
	using MSC
In-Reply-To: <1237906159.31.0.817735827451.issue5553@psf.upfronthosting.co.za>
Message-ID: <1274132312.92.0.784982584328.issue5553@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5553>
_______________________________________

From report at bugs.python.org  Mon May 17 23:48:24 2010
From: report at bugs.python.org (Alberto Trevino)
Date: Mon, 17 May 2010 21:48:24 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274130745.73.0.511398745991.issue8739@psf.upfronthosting.co.za>
Message-ID: <201005171548.26700.alberto@byu.edu>


Alberto Trevino <alberto at byu.edu> added the comment:

> Giampaolo Rodola' <g.rodola at gmail.com> added the comment:
> 
> Some comments:
> 
> Is RFC 5321 completely implemented? Otherwise I would turn this in "as
> defined in RFC 821 and part of RFC 5321".

RFC 5321 obsoletes RFCs 821, 974, 1869 and 2821.  I don't think we should 
make reference to them anymore.  Perhaps say something like "implements RFC 
5321 which supersedes RFC 821."

As to how complete the implementation is, section 4.5.1 of RFC 5321 
specifies the following as the minimum set of commands that should be 
supported in a conforming specification: EHLO, HELO, MAIL, RCPT, DATA, RSET, 
NOOP, QUIT, VRFY.  The only gray area is VRFY which is supposed to see if a 
mailbox exists for a particular user.  Since that function cannot be easily 
performed in this proxy smtpd server, section 3.5.3 states a 252 reply code 
should be returned.  My patch returns code 252 if self.__getaddr returns 
true, or 502 if it returns false.

> > - Implement DATA size limit (32 MiB by default)
> I couldn't find any reference to this in RFC 5321. Is it recommended
> somewhere else maybe? Also, issue 2518 and issue 1745035 are somewhat
> related with this specific problem.

It is not, but just seemed like good practice to advertise the limit in EHLO 
and enforce it.  My patch doesn't do a good job of enforcing it since it 
enforces it before doing process_message.  The problems with 2518 and 
1745035 are still there.

> Since you implemented HELP command in the first place it would be good to
> do it completely.

RFC 5321 doesn't specify it must accept arguments, but I agree it is a good 
idea.  I'll work on that and submit a new patch.

> Too bad smtpd currently lacks a test suite.
> Before going any further with this issue I would recommend to write tests
> first. I have a patch for adding a basic test suite for smtpd module I
> hope I'll be able to submit within this week.

It would be great if you could implement a test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Tue May 18 00:53:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 17 May 2010 22:53:20 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1274136800.45.0.903938317879.issue8446@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Maybe this is due to webbrowser dependency on "ic" module.

Patch not tested.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
keywords: +patch
nosy: +flox, ronaldoussoren
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7 -Python 3.2
Added file: http://bugs.python.org/file17384/issue8446_icglue_webbrowser.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Tue May 18 01:06:43 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 May 2010 23:06:43 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274137603.27.0.89406169907.issue8739@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> It is not, but just seemed like good practice to advertise the limit in 
> EHLO and enforce it.  My patch doesn't do a good job of enforcing it 
> since it enforces it before doing process_message.  The problems with 
> 2518 and 1745035 are still there.

Then I doubt it would be a good idea, also because the following comment added in issue 1745035 should still stand:

> The patch does not work as Giampaolo intends.  If the patch were 
> applied as-is, no emails longer than 998 bytes could be sent.

Personally I think there's no other way to gracefully solve this other than using a tempfile to store the data, but since I'm not a user of the module I'm going to let someone else comment about this.

> RFC 5321 doesn't specify it must accept arguments, but I agree it is 
> a good idea.  I'll work on that and submit a new patch.

If there's no RFC which states that, then I would provide arguments for HELP *only* if that is a common practice amongst smtp servers.

----------
nosy: +josiah.carlson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Tue May 18 01:11:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 17 May 2010 23:11:10 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1274137870.61.0.273792821288.issue8727@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Sorry about that. I guess I should have been more explicit when I said that "I have flagged the test as an expected failure" that meant I made it pass in the test suite until I get a chance to fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Tue May 18 01:12:45 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 May 2010 23:12:45 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274137965.22.0.718085313473.issue3051@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Tue May 18 01:14:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 17 May 2010 23:14:11 +0000
Subject: [issue8728] 2.7 regression in httplib.py: AttributeError: 'NoneType'
	object has no attribute 'makefile'
In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>
Message-ID: <1274138051.1.0.90407077937.issue8728@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8728>
_______________________________________

From report at bugs.python.org  Tue May 18 01:15:16 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 17 May 2010 23:15:16 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274138116.0.0.609048259253.issue5753@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attempting to summarize IRC discussion about this.

PySys_SetArgv is used to set up sys.argv   There is plenty of code which assumes that this is a list containing at least a zeroth string element; for example warnings.warn (see msg89688).

It seems reasonable for an program that embeds Python to have no arguments, and for this case, it makes sense for sys.argv to be [""]  (i.e. a list containing a single empty string).

However, in this case, it doesn't necessarily make sense to prepend the empty string to the front of sys.path

Looking through Python/sysmodule.c: if argc is 0 in the call to PySys_SetArgv, it looks like makeargvobject makes sys.argv be [""] (which is good), but it looks like it uses argc[0]  (as "argv") to prepend sys.path.

My reading of PySys_SetArgv is that if argv is NULL, then "char *argv0 = argv[0];" will read through NULL and thus will segfault on a typical platform.  

So one possible way to handle this might be to support PySys_SetArgv(0, NULL) as signifying that sys.argv should be set to [""] with no modification of sys.path

This Google code search for "pysys_setargv(0" shows 25 hits:
http://www.google.com/codesearch?hl=en&lr=&q=pysys_setargv\(0&sbtn=Search

Hoever, the function is complicated, and adding more special-cases seems error-prone.

I favor Antoine's approach in http://bugs.python.org/file13860/setargvex.patch of adding a new API entry point, whilst maximizing compatibilty for all of the code our there using the existing entry point.

I think that both the old and the new entry point need to have better documentation, in particular, spelling out the meaning of the args, what the effect of argc==0 is, and that argv must be non-NULL in the old entry point, but may be NULL for argc==0 in the new entry point (assuming that I'm reading that correctly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Tue May 18 03:26:25 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 18 May 2010 01:26:25 +0000
Subject: [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/test.html#test.test_support.captured_stdout

"This is a context manager than runs the with statement body using a StringIO.StringIO object as sys.stdout."

I think "than" is typo of "that".

----------
assignee: docs at python
components: Documentation
messages: 105946
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Maybe typo in doc
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8744>
_______________________________________

From report at bugs.python.org  Tue May 18 04:31:30 2010
From: report at bugs.python.org (Dan Buch)
Date: Tue, 18 May 2010 02:31:30 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274149890.66.0.891013281175.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file17385/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Tue May 18 04:57:49 2010
From: report at bugs.python.org (Dan Buch)
Date: Tue, 18 May 2010 02:57:49 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274151469.16.0.571609429391.issue8591@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

The attached mkpkg-round-of-pylinting.patch is known to cleanly apply to tarek's branch @ 541f90ef0636

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Tue May 18 05:29:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:29:14 +0000
Subject: [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <20100518032902.GA2282@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed it in revision 81279 and other branches.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8744>
_______________________________________

From report at bugs.python.org  Tue May 18 05:29:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:29:55 +0000
Subject: [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <1274153395.2.0.997066783435.issue8744@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8744>
_______________________________________

From report at bugs.python.org  Tue May 18 05:38:48 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:38:48 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1274153928.76.0.330353932072.issue8619@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The functionality provided by urllib.request._urlopener can be accomplished in a more natural way using build_opener. Historically, _urlopener was there for urllib and build_opener style came in urllib2.

So, I think, this can be safely be removed from the docs considering David's suggestion that its better not to advertise _methods in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8619>
_______________________________________

From report at bugs.python.org  Tue May 18 05:56:07 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:56:07 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1274154967.69.0.985592909328.issue8619@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Actually, I see certain use-cases of _urlopener in py3k. Most visible one being urllib.request.urlretrieve and also URLOpener.open which is different from build_opener way of doing things.

- But still, public exposure of overriding globals to can be removed. There is no harm in the functionality. In py3k, users should resort to build_opener style of doing than use FancyURLOpener or URLOpener which are present for backward compatibility reasons only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8619>
_______________________________________

From report at bugs.python.org  Tue May 18 06:07:12 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 04:07:12 +0000
Subject: [issue8619] Doc bug for urllib.request._urlopener in Python 3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1274155632.35.0.125267964152.issue8619@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Removed in r81283 and r81284.
With respect to the technical details of exposing this functionality for _urlretrieve and URLOpener.
- users can still do it.
- There is a better way, if the other global _opener be served for the same purpose, so that build_opener can be used. There is TODO mentioned in the code, let me see if it can be accomplished without any problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8619>
_______________________________________

From report at bugs.python.org  Tue May 18 06:08:03 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 18 May 2010 04:08:03 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274155683.12.0.337898465376.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Attached is a patch that implements part of the additions.  More specifically, the 'T{}' syntax and the ability to place byte-order specifiers ('<', '>', '@', '^', '!", '=') anywhere in the struct string.  

The changes dictated by the PEP are so big that it is better to split things up into multiple patches.  These two features will lay some ground work and are probably less controversial than the others.

Surely some more tweaks will be needed, but I think what I have now is at least good enough for review.  I tested on OS X 10.6 and Ubuntu 10.4.  I also used valgrind and 'regrtest.py -R:' to check for memory and 
reference leaks, respectively.

----------
Added file: http://bugs.python.org/file17386/struct-string.py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Tue May 18 07:05:01 2010
From: report at bugs.python.org (Ashley Sands)
Date: Tue, 18 May 2010 05:05:01 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1274159101.6.0.579934553953.issue8667@psf.upfronthosting.co.za>


Ashley Sands <ashley.j.sands at gmail.com> added the comment:

Hi Brett,

I would like to contribute to the open source community and Python is my favourite language, so I figured I would begin here. But I have never done this before, so I am a open-source-contributor-newbie.

So to resolve this issue, I would need to:
Check out the source for Python 3.2.
Locate the importlib module.
Find the file containing the documentation (I presume it would be __init__.py).
Then insert some text and a URL to PEP 3147.
Then commit the change.

Is this the right approach?

----------
nosy: +ashleyjsands

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Tue May 18 08:08:12 2010
From: report at bugs.python.org (Goplat)
Date: Tue, 18 May 2010 06:08:12 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>


New submission from Goplat <mrnobo1024 at yahoo.com>:

Reading the list of files in a .zip takes a while because several seeks are done for each entry, which (on Windows at least) flushes stdio's buffer and forces a system call on the next read. For large .zips the effect on startup speed is noticeable, being perhaps 50ms per thousand files. Changing the read_directory function to read the central directory entirely sequentially would cut this time by more than half.

----------
components: Interpreter Core
files: zipimport_speedup.patch
keywords: patch
messages: 105954
nosy: Goplat
priority: normal
severity: normal
status: open
title: zipimport is a bit slow
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file17387/zipimport_speedup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Tue May 18 09:12:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 07:12:59 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274166779.18.0.380335776519.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for this.

Any chance you could upload the patch to Rietveld (http://codereview.appspot.com/) for ease of review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Tue May 18 09:59:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 May 2010 07:59:02 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274169542.21.0.437688153342.issue3051@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

All six of the rich comparisons need to be implemented or the result is undefined.  This module never made guarantees for objects defining only one of the six.

We could change the pure python code to handle both __lt__ and __le__ but that would make it much harder to read and understand.  The C version supports and that is what runs by default.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Tue May 18 11:05:22 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 May 2010 09:05:22 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

os.chflags isn't `available' even though chflags support is available on the system:

>>> filter(lambda x: x.startswith('chflags'), dir(os))
[]
>>> platform.uname()
('FreeBSD', 'bayonetta.local', '9.0-CURRENT', 'FreeBSD 9.0-CURRENT #0 r206173M: Mon Apr 26 22:45:06 PDT 2010     root at bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata', 'amd64', 'amd64')
>>> filter(lambda x: x.startswith('chflags'), dir(os))
[]
>>> sys.version
'2.6.5 (r265:79063, May 16 2010, 23:37:42) \n[GCC 4.2.1 20070719  [FreeBSD]]'

I'm looking into why this is not properly detected via configure (here's the snippet though):

configure:17257: checking for chflags
configure:17288: cc -o conftest -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=nocona -D__wchar_t=wchar_t  -DTHREAD_STACK_SIZE=0x100000  -pthread  conftest.c  >&5
conftest.c:173: error: expected identifier or '(' before '[' token
In file included from /usr/include/sys/_types.h:33,
                 from /usr/include/sys/_timespec.h:37,
                 from /usr/include/sys/stat.h:42,
                 from conftest.c:174:
/usr/include/machine/_types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__int_least8_t'
In file included from /usr/include/sys/time.h:37,
                 from /usr/include/sys/stat.h:99,
                 from conftest.c:174:
/usr/include/sys/types.h:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int8_t'
conftest.c:182: error: expected identifier or '(' before ']' token
configure:17291: $? = 1

Compiling the standalone test works:

$ cat ~/test_chflags.c 
#include <sys/stat.h>
#include <unistd.h>
int main(int argc, char*argv[])
{
  if(chflags(argv[0], 0) != 0)
    return 1;
  return 0;
}
$ gcc -o ~/test_chflags ~/test_chflags.c
$ echo $?
0

Also, another sidenote: nowhere is *chflags(2) considered a POSIX feature (I doublechecked opengroup.org and Google). It is strictly a _Unix_ feature. I say this because the POSIX functionality tester explicitly looks for this `POSIX' compatible feature.

----------
messages: 105957
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: *chflags detection broken on FreeBSD 9-CURRENT
type: compile error
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue May 18 11:13:41 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 18 May 2010 09:13:41 +0000
Subject: [issue8747] Autoconf tests in python not portably correct
In-Reply-To: <1274174021.7.0.201652385814.issue8747@psf.upfronthosting.co.za>
Message-ID: <1274174021.7.0.201652385814.issue8747@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

A number of features are being blindly enabled on python that aren't correct from a porting standpoint; a handful in configure.in I noticed are:

# The later defininition of _XOPEN_SOURCE disables certain features
# on Linux, so we need _GNU_SOURCE to re-enable them (makedev, tm_zone).
AC_DEFINE(_GNU_SOURCE, 1, [Define on Linux to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on NetBSD, so we need _NETBSD_SOURCE to re-enable
# them.
AC_DEFINE(_NETBSD_SOURCE, 1, [Define on NetBSD to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on FreeBSD, so we need __BSD_VISIBLE to re-enable
# them.
AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# u_int on Irix 5.3. Defining _BSD_TYPES brings it back.
AC_DEFINE(_BSD_TYPES, 1, [Define on Irix to enable u_int])

# The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables
# certain features on Mac OS X, so we need _DARWIN_C_SOURCE to re-enable
# them.
AC_DEFINE(_DARWIN_C_SOURCE, 1, [Define on Darwin to activate all library features])

these are only applicable on certain platforms and thus, shouldn't be enabled on all platforms (the default should be off, and then the values should be tuned according to the platform detection performed by autoconf).

----------
components: Build
messages: 105958
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Autoconf tests in python not portably correct
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8747>
_______________________________________

From report at bugs.python.org  Tue May 18 12:02:42 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 18 May 2010 10:02:42 +0000
Subject: [issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>
Message-ID: <1274176962.41.0.541790156479.issue8732@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

How many tests did you run?  My two tests were minutes apart.  I have the feeling that this has something to do with cacheing behavior on the server.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8732>
_______________________________________

From report at bugs.python.org  Tue May 18 12:09:14 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 18 May 2010 10:09:14 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1274177354.66.0.0484052894542.issue8745@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

When I perform some test on debian-5.0, I see the timing results almost the same before and after apply your patch(I modified the patch to against the trunk). 

Could you give some test result on windows? I can't see the speedups on debian-5.0.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Tue May 18 12:36:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 10:36:06 +0000
Subject: [issue8640] subprocess: canonicalize env to bytes on Unix (Python3)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1274178966.99.0.936631838756.issue8640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

os.exeve() and os.exevpe() should also canonicalize env to bytes.

os.exeve() and os.exevpe(), but not os._exevpe() to avoid doing it twice (once in subprocess, once in os._exevpe). Patch os._exevpe() is not enough because subprocess doesn't call it on Unix if _subprocessposix module is present.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Tue May 18 12:36:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 10:36:30 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274178990.74.0.934611505752.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hum, os.get_exec_path() has no test for the new features (support b'PATH' key and bytes value).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Tue May 18 12:37:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 10:37:16 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

I've just discovered that integer-to-complex comparisons are broken, in all versions of Python that I've tested.  It looks as though the integer is first converted to a complex number, and then the two complex numbers are compared.  That's not correct, and it's contrary to what happens for floats, where there's special handling in place to make sure that exact values are compared.  This leads to loss of transitivity of equality:

>>> n = 2**53+1
[51529 refs]
>>> float(n) == complex(n)  # expect True
True
[51531 refs]
>>> n == float(n)           # expect False
False
[51531 refs]
>>> n == complex(n)         # expect False, but Python returns True
True
[51531 refs]

Apparently the SAGE folks noticed this some time ago, but AFAICT didn't report it as a bug. See http://www.mail-archive.com/sage-devel at googlegroups.com/msg20891.html

For a complex number z and an integer i, 'z == i' should be exactly equivalent to 'z.real == i and z.imag == 0.0'.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 105963
nosy: mark.dickinson
priority: high
severity: normal
status: open
title: integer-to-complex comparisons give incorrect results
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/issue8748>
_______________________________________

From report at bugs.python.org  Tue May 18 12:41:21 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 18 May 2010 10:41:21 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274179281.02.0.504362883778.issue8741@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Tue May 18 12:42:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 10:42:33 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274179353.68.0.683388284327.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Right thread, wrong message.  That should have been:

http://www.mail-archive.com/sage-devel at googlegroups.com/msg20839.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Tue May 18 12:51:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 18 May 2010 10:51:12 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1274179872.3.0.319036823782.issue8727@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks, Antoine filled me in on IRC just before my 'net connection went down for many hours.  The good news is that I have a fix for this and will commit it in a little while.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Tue May 18 13:34:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 May 2010 11:34:04 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1274182444.5.0.740543865233.issue2281@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Nir, would you be interested in looking at this?

----------
nosy: +nirai
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Tue May 18 13:35:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 May 2010 11:35:34 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1274182534.46.0.357959720962.issue8745@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon
stage:  -> patch review
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Tue May 18 14:06:30 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 18 May 2010 12:06:30 +0000
Subject: [issue8749] Cruft in object.c: PyObject_GenericGetAttr
In-Reply-To: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>
Message-ID: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>


New submission from Yaniv Aknin <yaniv.aknin at gmail.com>:

While reading the source I saw that recent py3k has this in Objects/object.c (reasonably recent trunk has it as well):

#if 0 /* XXX this is not quite _PyType_Lookup anymore */
    /* Inline _PyType_Lookup */
    { ... removed ...
    }
#else
    descr = _PyType_Lookup(tp, name);
#endif

This was commented out (on trunk, I assumed on py3k it was for the same reason) by amaury.forgeotdarc on revision 59943, when a patch to the real _PyType_Lookup was applied.

I think it can be safely removed.

----------
components: Interpreter Core
messages: 105967
nosy: Yaniv.Aknin
priority: normal
severity: normal
status: open
title: Cruft in object.c: PyObject_GenericGetAttr
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8749>
_______________________________________

From report at bugs.python.org  Tue May 18 14:10:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 12:10:28 +0000
Subject: [issue8749] Cruft in object.c: PyObject_GenericGetAttr
In-Reply-To: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>
Message-ID: <1274184628.87.0.489578838799.issue8749@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8749>
_______________________________________

From report at bugs.python.org  Tue May 18 14:17:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 12:17:47 +0000
Subject: [issue8749] Cruft in object.c: PyObject_GenericGetAttr
In-Reply-To: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>
Message-ID: <1274185067.5.0.364321573706.issue8749@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like r59944 to me.

Amaury, any objections to removing this '#if 0' code?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8749>
_______________________________________

From report at bugs.python.org  Tue May 18 14:22:19 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 18 May 2010 12:22:19 +0000
Subject: [issue8749] Cruft in object.c: PyObject_GenericGetAttr
In-Reply-To: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>
Message-ID: <1274185339.33.0.480083205781.issue8749@psf.upfronthosting.co.za>


Yaniv Aknin <yaniv.aknin at gmail.com> added the comment:

Oops, of course I meant r59944, off by one. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8749>
_______________________________________

From report at bugs.python.org  Tue May 18 14:22:26 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 18 May 2010 12:22:26 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274185346.49.0.791362327271.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Sure - http://codereview.appspot.com/1258041

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Tue May 18 14:44:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 May 2010 12:44:27 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1274186667.71.0.0933152645094.issue2281@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Regarding the calibrating loop when using ASM timestamp counters, there's one problem if the thread gets preempted in the middle of the loop: the calibration will return incorrect results. Perhaps a way of avoiding this would be to call nanosleep(1 ns) just before the loop, which should relinquish the current timeslice.

Another issue can appear when threads migrate from one CPU core to another, according to Wikipedia: ?AMD processors up to the K8 core always incremented the time-stamp counter every clock cycle.[5] Thus, power management features were able to change the number of increments per second, and the values could get out of sync between different cores or processors in the same system.?

Perhaps using clock_gettime(CLOCK_REALTIME or CLOCK_MONOTONIC) is better than using raw ASM timestamp counters, when available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Tue May 18 15:00:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 13:00:55 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1274187655.42.0.555465782213.issue2281@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Tue May 18 15:09:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 May 2010 13:09:12 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1274188152.1.0.655339626932.issue2281@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, the calibration loop actually looks correct in case of preemption, since it simply divides the TSC delta by the elapsed physical time (and both continue increasing monotonously when another thread runs). It is still vulnerable to the thread migration problem, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Tue May 18 15:20:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 13:20:17 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1274159101.6.0.579934553953.issue8667@psf.upfronthosting.co.za>
Message-ID: <20100518132005.GA2725@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Ashley Sands wrote:
> Is this the right approach?

Follow the process mentioned here:
http://www.python.org/dev/faq/

And create a patch against Docs/library/importlib.rst with the
reference to PEP 3147 included. That is it. Look for other places
where it might need reference too.

Attach the patch to this bug report.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Tue May 18 15:44:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 13:44:22 +0000
Subject: [issue8750] Many of MutableSet's methods assume that the other
	parameter is not self
In-Reply-To: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>
Message-ID: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

For example, here is one of MutableSet's methods:

    def __isub__(self, it):
        for value in it:
            self.discard(value)
        return self

However, if I do "x -= x", then it mutates my set-like object during iteration, which even the built-in set does not support.  ior, iand, and ixor have the same problem.

I'm working on running test_set.py (with suitable modifications) on my class that derives from collections.MutableSet, so I'm going to be bumping into all kinds of fun problems like this.

I'm going to override the methods in my class, and I can contribute my new methods back to Python as a patch once they're working.

----------
assignee: stutzbach
components: Library (Lib)
messages: 105974
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: Many of MutableSet's methods assume that the other parameter is not self
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8750>
_______________________________________

From report at bugs.python.org  Tue May 18 15:45:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 13:45:55 +0000
Subject: [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274190355.47.0.343554353542.issue8742@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is the proper link:
http://www.cs.princeton.edu/research/techreps/TR-554-97

Fixed those references in the code too.

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8742>
_______________________________________

From report at bugs.python.org  Tue May 18 15:54:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 May 2010 13:54:46 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274190886.31.0.0119893803348.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I will try to write better documentation.

----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Tue May 18 16:08:26 2010
From: report at bugs.python.org (Nir Aides)
Date: Tue, 18 May 2010 14:08:26 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1274191706.1.0.825505198549.issue2281@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> Nir, would you be interested in looking at this?

yes, I'll take a look, but will take me a few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Tue May 18 16:15:43 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 18 May 2010 14:15:43 +0000
Subject: [issue8727] test_import failure
In-Reply-To: <1273957861.75.0.135836839803.issue8727@psf.upfronthosting.co.za>
Message-ID: <1274192143.02.0.539268458027.issue8727@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r81290

----------
assignee: brett.cannon -> barry
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8727>
_______________________________________

From report at bugs.python.org  Tue May 18 16:25:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 14:25:52 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <20100518142538.GB2725@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is a platform specific bug. It is happening only on windows.
BTW, makelink should not have been called for this file, because it
is not a link or symlink, but a regular file.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Tue May 18 16:51:54 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Tue, 18 May 2010 14:51:54 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274194314.53.0.627555753924.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

> My reading of PySys_SetArgv is that if argv is NULL, then 
> "char *argv0 = argv[0];" will read through NULL and thus will
> segfault on a typical platform.

Right.

> I favor Antoine's approach in
> http://bugs.python.org/file13860/setargvex.patch of adding a new API
> entry point, whilst maximizing compatibilty for all of the code our
> there using the existing entry point.

Sadly, this won't help existing applications affected by this problem, without all of them needing to be changed.

My change proposed in msg90336 won't help either, at least not in all cases.  Apps that call PySys_SetArgv with 1, { "myappname", NULL } can still be tricked to add full CWD path at the beginning of sys.path on platforms with realpath().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Tue May 18 16:56:49 2010
From: report at bugs.python.org (Vignesh)
Date: Tue, 18 May 2010 14:56:49 +0000
Subject: [issue8751] Threading and KeyError: 51
In-Reply-To: <1274194609.13.0.380830310916.issue8751@psf.upfronthosting.co.za>
Message-ID: <1274194609.13.0.380830310916.issue8751@psf.upfronthosting.co.za>


New submission from Vignesh <vigneshk at mail.med.upenn.edu>:

I have a python script which runs a particular script large number of times (for monte carlo purpose) and the way I have scripted it is that, I queue up the script the desired number of times it should be run then I spawn threads and each thread runs the script once and again when its done.

Once the script in a particular thread is finished, the output is written to a file by accessing a lock (so my guess was that only one thread accesses the lock at a given time). Once the lock is released by one thread, the next thread accesses it and adds its output to the previously written file and rewrites it. 

I am not facing a problem when the number of iterations is small like 10 or 20 but when its large like 50 or 150, python returns a KeyError: 51 telling me element doesn't exist and the error it points out to is within the lock which puzzles me since only one thread should access the lock at once and I do not expect an error. 

This is the class I use:

class errorclass(threading.Thread):
    
     def __init__(self, queue):
         self.__queue=queue
         threading.Thread.__init__(self)
     
     def run(self):
         while 1:
               item = self.__queue.get()
               if item is None: break
               result = myfunction()
               lock = threading.RLock()
               lock.acquire()
               ADD entries from current thread to entries in file and
               REWRITE FILE           
               lock.release()

----------
components: IDLE
messages: 105981
nosy: Vignesh.K
priority: normal
severity: normal
status: open
title: Threading and KeyError: 51
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8751>
_______________________________________

From report at bugs.python.org  Tue May 18 16:59:37 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 18 May 2010 14:59:37 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274194777.25.0.611451217401.issue8741@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

@senthil: Yes, this is a platform-specific problem. The code that is failing is in fact supposed to somehow "emulate" symlink and hardlink extraction on platforms that don't support these, e.g. Windows. What tarfile is trying to do here is to extract links as if they were regular files.

@sridhar: Thanks for the detailed report. I am currently working on the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Tue May 18 17:21:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 15:21:12 +0000
Subject: [issue8752] set_contains,
	etc. should check for collections.Set in addition to PySet_Check
In-Reply-To: <1274196072.83.0.116605329158.issue8752@psf.upfronthosting.co.za>
Message-ID: <1274196072.83.0.116605329158.issue8752@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

For operations that test membership in a set, Python coerces sets and subclasses of set into a temporary frozenset before testing membership.

For example, this works:

>>> set() in set([frozenset()])
True

Although the set() is not hashable itself, Python creates a temporary frozenset() out of the set().  It should do the same for user-types derived from collections.Set, so they can inter-operate in the same way.

In setobject.c, the following methods behave in the described manner: set_contains, set_remove, and set_discard.

----------
components: Interpreter Core
messages: 105983
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: set_contains, etc. should check for collections.Set in addition to PySet_Check
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8752>
_______________________________________

From report at bugs.python.org  Tue May 18 17:28:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 May 2010 15:28:58 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274196538.82.0.0443673040783.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

More fun arising from the current complex comparison implementation:  usually you can put a complex number and an integer into the same set:

>>> {1, 2j}  # (Python 3 code)
{1, 2j}
>>> s = {10**1000, 2j}  # huge integers no problem

But if you happen to pick the wrong combination....

>>> x, n = 9.3 + 0j, 10**300*(2**64-1)+hash(9.3)
>>> x
(9.3+0j)
>>> n
18446744073709551615000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002107349606
>>> {x, n}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Tue May 18 17:38:21 2010
From: report at bugs.python.org (Peter Portante)
Date: Tue, 18 May 2010 15:38:21 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1274197101.3.0.113937990991.issue7946@psf.upfronthosting.co.za>


Changes by Peter Portante <peter.a.portante at gmail.com>:


----------
nosy: +portante

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue May 18 17:41:34 2010
From: report at bugs.python.org (Mattias Nilsson)
Date: Tue, 18 May 2010 15:41:34 +0000
Subject: [issue8751] Threading and KeyError: 51
In-Reply-To: <1274194609.13.0.380830310916.issue8751@psf.upfronthosting.co.za>
Message-ID: <1274197294.46.0.179598846608.issue8751@psf.upfronthosting.co.za>


Mattias Nilsson <mattias.o.nilsson at gmail.com> added the comment:

Correct me if I'm wrong, but you seem to be creating a new lock object for each iteration in the loop?
If other threads should be blocked, they must be using the same lock object and you can't create new ones for each time you want to write something to the file.

This doesn't seem to be a Python bug at all, but instead a problem in your implementation. It might be better to post this at stackoverflow.com or somewhere similar.

----------
nosy: +Mattias.Nilsson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8751>
_______________________________________

From report at bugs.python.org  Tue May 18 17:45:33 2010
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 18 May 2010 15:45:33 +0000
Subject: [issue8751] Threading and KeyError: 51
In-Reply-To: <1274194609.13.0.380830310916.issue8751@psf.upfronthosting.co.za>
Message-ID: <1274197533.37.0.815399629989.issue8751@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

As suggested, please post in c.l.py or other forums. Open a bug here only if you are sure that there is a bug in Python.

----------
nosy: +draghuram
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8751>
_______________________________________

From report at bugs.python.org  Tue May 18 17:55:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 15:55:08 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
Message-ID: <1274198108.41.0.978364995742.issue8753@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
assignee: stutzbach
components: Documentation
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_ReprEnter and Py_ReprLeave are undocumented
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Tue May 18 18:01:24 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 18 May 2010 16:01:24 +0000
Subject: [issue8741] 2.7 regression in tarfile: IOError: link could not be
	created
In-Reply-To: <1274118345.32.0.801692184283.issue8741@psf.upfronthosting.co.za>
Message-ID: <1274198484.93.0.002413608631.issue8741@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Thanks - just a suggestion: it may be a good idea to add a test case for this makelink emulation code.

Also, any thoughts on raising (a derived class of) TarError instead of IOError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8741>
_______________________________________

From report at bugs.python.org  Tue May 18 19:03:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 May 2010 17:03:20 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

ImportError messages should quote the name it cannot import since the actual problem may be whitespace in the name that is currently invisible in the message.  In other words, display

ImportError: no module named 'bad name\r'

instead of

ImportError: no module named bad name

This defect lead to the current python-list thread
  pickle unable to load collection

Peter Otten figured out that it was unable to load 'collections\r' rather than 'collections', which he demonstrated with

>>> >>> try: pickle.loads(garbled_data)
... except ImportError as e:
...     e
...
ImportError('No module named collections\r',)

The OP used 2.6, I tested 3.1, hence presume, after searching tracker issues, that this applies to 2.7 and 3.2 as well.

I marked this as a bug since the current message is wrong and misleading. I suspect the same may be true of a few other error messages, but I cannot think of any at the moment.

----------
components: Interpreter Core
messages: 105988
nosy: tjreedy
priority: normal
severity: normal
status: open
title: ImportError: quote bad module name in message
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/issue8754>
_______________________________________

From report at bugs.python.org  Tue May 18 19:16:14 2010
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Tue, 18 May 2010 17:16:14 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274202974.88.0.19412128503.issue3051@psf.upfronthosting.co.za>


Maciek Fijalkowski <fijal at genesilico.pl> added the comment:

I cannot honestly make much sense from what you said. My concern is whether python and C version behaves the same or not. It seems that in current version they intentionally behave differently, for simplicity and it's against policy of having the same functionality. I agree that it's an obscure corner case, but still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Tue May 18 19:19:05 2010
From: report at bugs.python.org (Henry Precheur)
Date: Tue, 18 May 2010 17:19:05 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1273859890.02.0.278198724861.issue6419@psf.upfronthosting.co.za>
Message-ID: <20100518171855.GA7700@banane.novuscom.net>


Henry Precheur <henry at precheur.org> added the comment:

The patch works well with on amd64/OpenBSD-current (CVS from May 14 or
15).

I don't have access to a 4.7-stable right now.

On Fri, May 14, 2010 at 05:58:10PM +0000, Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> Mark, thanks. - The patch is good on OpenBSD-4.5-i386-Celeron,
> but I get additional failures on OpenBSD-4.7-beta-amd64-QEMU.
> 
> This could be the result of running a beta under qemu.
> 
> Henry, could you confirm if the patch works on amd64/OpenBSD-4.7-stable?
> 
> 
> 
> ======================================================================
> FAIL: test_create_event (test.test_kqueue.TestKQueue)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/home/stefan/svn/py3k/Lib/test/test_kqueue.py", line 29, in test_create_event
>     self.assertEqual(ev.ident, fd)
> AssertionError: 562945658454018 != 2
> 
> ======================================================================
> FAIL: test_queue_event (test.test_kqueue.TestKQueue)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/home/stefan/svn/py3k/Lib/test/test_kqueue.py", line 130, in test_queue_event
>     (server.fileno(), select.KQ_FILTER_WRITE, flags)])
> AssertionError: Lists differ: [(1688841270329350, -2, 5), (1... != [(6, -2, 0), (7, -2, 0)]
> 
> First differing element 0:
> (1688841270329350, -2, 5)
> (6, -2, 0)
> 
> - [(1688841270329350, -2, 5), (1688841270329351, -2, 5)]
> + [(6, -2, 0), (7, -2, 0)]
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6419>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Tue May 18 19:25:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 17:25:08 +0000
Subject: [issue8513] subprocess: support bytes program name (POSIX)
In-Reply-To: <1272062527.11.0.850135595207.issue8513@psf.upfronthosting.co.za>
Message-ID: <1274203508.63.0.377022802342.issue8513@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r81291 + r81292 (py3k).

The final commit contains much more tests ;-) I will watch the buildbot next hours and block the commit in 3.1.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8513>
_______________________________________

From report at bugs.python.org  Tue May 18 19:29:28 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 18 May 2010 17:29:28 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1274203768.0.0.916451530956.issue7753@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Tue May 18 19:30:44 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 18 May 2010 17:30:44 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1274203844.12.0.797127505617.issue7753@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Sorry for the nosy. There is something going wrong with my Firefox caching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Tue May 18 19:37:30 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 May 2010 17:37:30 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1274204250.38.0.51330359859.issue8667@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for wanting to help, Ashley! And Senthil hit all the right points. If you need any help with the code checkout you can read http://www.python.org/dev/setup/ (and in general dev questions are hopefully answered by something linked from http://www.python.org/dev/ ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Tue May 18 19:47:51 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 May 2010 17:47:51 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274204871.81.0.992941474507.issue8754@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I guess it's a question of readability. Does::

  ImportError: No module named mod

read better than::

  ImportError: No module named 'mod'

In my eyes it doesn't by much, so switching to using repr() seems reasonable.

This can't be changed in released versions of Python as that could break someone's doctests. So making this only for 2.7 and 3.2.

----------
nosy: +brett.cannon
priority: normal -> low
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Tue May 18 19:48:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 May 2010 17:48:02 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274204882.09.0.863054693441.issue8754@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Tue May 18 20:10:53 2010
From: report at bugs.python.org (Dylan Canfield)
Date: Tue, 18 May 2010 18:10:53 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1274206253.29.0.375431327469.issue8335@psf.upfronthosting.co.za>


Dylan Canfield <fire.phreak at gmail.com> added the comment:

I am having the exact same problem with test_distutils failing on a clean env. Did reverting the changes in r72637 fix your problem?

----------
nosy: +Canfield

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8335>
_______________________________________

From report at bugs.python.org  Tue May 18 20:21:53 2010
From: report at bugs.python.org (Andy Harrington)
Date: Tue, 18 May 2010 18:21:53 +0000
Subject: [issue8755] idle crash  UnicodeDecodeError utf-8 codec
In-Reply-To: <1274206913.48.0.235847350829.issue8755@psf.upfronthosting.co.za>
Message-ID: <1274206913.48.0.235847350829.issue8755@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

I was editing in idle in python 3.1, typing away.  I had been doing it for hours.  I do not think I had jumped to the shell window.  Suddenly idle crashed, with this error message in the the  ubuntu 9,10 terminal window:

Traceback (most recent call last):
  File "/usr/bin/idle3", line 5, in <module>
    main()
  File "/usr/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/usr/lib/python3.1/tkinter/__init__.py", line 1012, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding

I do not know what key combination I had just typed.  I may have just hit a crtl or alt combination.

The hardware is an Acer notebook.

This is certainly an exception that should be caught!  I did not get to even save my work.

----------
components: IDLE
messages: 105996
nosy: andyharrington
priority: normal
severity: normal
status: open
title: idle crash  UnicodeDecodeError utf-8 codec
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8755>
_______________________________________

From report at bugs.python.org  Tue May 18 20:38:17 2010
From: report at bugs.python.org (Gavin Roy)
Date: Tue, 18 May 2010 18:38:17 +0000
Subject: [issue8756] Multiprocessing and UUID bug on Mac OSX
In-Reply-To: <1274207897.31.0.857172476403.issue8756@psf.upfronthosting.co.za>
Message-ID: <1274207897.31.0.857172476403.issue8756@psf.upfronthosting.co.za>


New submission from Gavin Roy <gmr at myyearbook.com>:

import multiprocessing
import uuid

def test():
    print str(uuid.uuid4())

p = multiprocessing.Pool(processes=4)
for x in xrange(0, 4):
  p.apply_async(test)

In MacOS:

Gavin-M-Roys-Office-iMac:kvpbench gmr$ python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>> 
>>> import multiprocessing
>>> import uuid
>>> 
>>> def test():
...     print str(uuid.uuid4())
... 
>>> p = multiprocessing.Pool(processes=4)
>>> for x in xrange(0, 4):
...   p.apply_async(test)
... 
<multiprocessing.pool.ApplyResult object at 0x10056bb90>
<multiprocessing.pool.ApplyResult object at 0x10064e690>
<multiprocessing.pool.ApplyResult object at 0x10064e750>
<multiprocessing.pool.ApplyResult object at 0x10064e710>
>>> 62c76035-e340-41c4-86b4-908660b73bb7
62c76035-e340-41c4-86b4-908660b73bb7
62c76035-e340-41c4-86b4-908660b73bb7
62c76035-e340-41c4-86b4-908660b73bb7

In Linux:

gmr at binti ~ $ python
Python 2.6.4 (r264:75706, Mar  9 2010, 17:27:45) 
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> import uuid
>>> 
>>> def test():
...     print str(uuid.uuid4())
... 
>>> p = multiprocessing.Pool(processes=4)
>>> for x in xrange(0, 4):
...   p.apply_async(test)
... 
<multiprocessing.pool.ApplyResult object at 0x7dd990>
<multiprocessing.pool.ApplyResult object at 0x86d310>
<multiprocessing.pool.ApplyResult object at 0x86d390>
<multiprocessing.pool.ApplyResult object at 0x86d410>
>>> 6121782c-008d-42db-9df5-bbf619fb6568
ee7d3ef8-1c54-4ab5-bf06-1eddf5bcf2cb
40efe282-65a5-4160-96ee-b4cc0d14029d
9eb799f2-a46c-41e8-901f-423177f3467d

----------
assignee: ronaldoussoren
components: Macintosh
messages: 105997
nosy: Gavin.Roy, ronaldoussoren
priority: normal
severity: normal
status: open
title: Multiprocessing and UUID bug on Mac OSX
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8756>
_______________________________________

From report at bugs.python.org  Tue May 18 20:52:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 May 2010 18:52:59 +0000
Subject: [issue8756] Multiprocessing and UUID bug on Mac OSX
In-Reply-To: <1274207897.31.0.857172476403.issue8756@psf.upfronthosting.co.za>
Message-ID: <1274208779.77.0.966238895809.issue8756@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> uuid.uuid4() generates non-unique values on OSX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8756>
_______________________________________

From report at bugs.python.org  Tue May 18 21:08:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 May 2010 19:08:52 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1274209732.97.0.0591406677247.issue8573@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve just checked the diff and the current trunk version of the file, and the change from ?os.strerror(err)? to ?strerror(err)? seems buggy to me.

----------
assignee: giampaolo.rodola -> 
nosy:  -giampaolo.rodola, josiahcarlson
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open
type: behavior -> crash
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Tue May 18 21:14:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 May 2010 19:14:35 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1274210075.75.0.657017693277.issue8573@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hopefully fixing yet another lovely browser or roundup forms friggin bug. Sorry.

----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola, josiahcarlson
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Tue May 18 21:16:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 18 May 2010 19:16:11 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1274210171.76.0.735613976828.issue8573@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Tue May 18 21:34:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 May 2010 19:34:21 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274211261.05.0.37450644403.issue8729@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Backport to 2.6 and 3.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Tue May 18 21:36:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 May 2010 19:36:33 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274211393.61.0.361252076672.issue8729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, I think this is a good candidate for backport. The ABCs are new and their APIs shouldn't contain any obvious bugs such as this.

----------
nosy: +pitrou
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Tue May 18 21:43:51 2010
From: report at bugs.python.org (Longpoke)
Date: Tue, 18 May 2010 19:43:51 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1274211831.65.0.920624814782.issue8573@psf.upfronthosting.co.za>


Longpoke <longpoke at gmail.com> added the comment:

Yes, it should definately be os.sterror. Dunno how I ended up omitting that, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Tue May 18 21:45:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 May 2010 19:45:35 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274211935.51.0.0521694476862.issue3051@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am closing this.  It would make no sense to change simple, pure python code to support objects implementing only one of the rich comparison methods.  People implementing rich comparisons need to implement all six if they want to guarantee total ordering and to be usable by various modules that need to be able to make comparisons.

FWIW, the C code is not guaranteed to be exactly the same in terms of implementation details, only the published API should be the same.  And, for this module, a decision was made for the C code to support only lists eventhough the pure python version supports any sequence.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Tue May 18 21:50:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 May 2010 19:50:53 +0000
Subject: [issue8752] set_contains,
	etc. should check for collections.Set in addition to PySet_Check
In-Reply-To: <1274196072.83.0.116605329158.issue8752@psf.upfronthosting.co.za>
Message-ID: <1274212253.92.0.600619819561.issue8752@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I don't think the set methods can make assumptions about whether instances of the Set API can be made frozen.  It is okay to restrict this to just instances of "set" where we know its internal structure and know that its elements are hashable (see the collections docs for an example of a non-hashable set).

Also, the collections.Set methods are supposed to be minimal.  They are not intended to mimic every aspect of regular set objects.

----------
nosy: +rhettinger
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8752>
_______________________________________

From report at bugs.python.org  Tue May 18 22:19:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 18 May 2010 20:19:07 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1274213947.82.0.910179039244.issue8573@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

It slipped under my radar as well. Thanks.
Fixed in r81294 (trunk), r81298 (2.6), r81299 (3.2) and r81300 (3.1) which also add tests and include NameError in the list of possible exceptions in case os.strerror() is not supported on the current platform (e.g. Windows CE) in which case "unknown error $number$" is returned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Tue May 18 22:39:51 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 18 May 2010 20:39:51 +0000
Subject: [issue8573] Buggy _strerror in asyncore
In-Reply-To: <1272573029.96.0.566961009055.issue8573@psf.upfronthosting.co.za>
Message-ID: <1274215191.35.0.14601100951.issue8573@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8573>
_______________________________________

From report at bugs.python.org  Tue May 18 22:41:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 20:41:54 +0000
Subject: [issue8640] subprocess: canonicalize env to bytes on Unix (Python3)
In-Reply-To: <1273185917.08.0.761086865943.issue8640@psf.upfronthosting.co.za>
Message-ID: <1274215314.53.0.119728890775.issue8640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch to fix #8513 does also fix the examples of this issue and so I think that the canonicalization is no more needed. I will only reopen the issue if I find a good reason to apply the patch :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8640>
_______________________________________

From report at bugs.python.org  Tue May 18 23:07:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 18 May 2010 21:07:34 +0000
Subject: [issue8757] Race condition when checking for set in set
In-Reply-To: <1274216854.13.0.448353373516.issue8757@psf.upfronthosting.co.za>
Message-ID: <1274216854.13.0.448353373516.issue8757@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

"some_set in some_set_of_sets" contains a race condition that can lead to odd behavior.  To perform the test, the set_contains() function in setobject.c creates a temporary frozenset object (t), swaps the bodies of some_set and t, checks if t is in some_set_of_sets, then swaps the bodies back.

Unfortunately, comparisons or hash functions may release the GIL, so the swapped bodies may be exposed on a different thread, i.e., "some_set in some_set_of_sets" may cause "some_set" to be empty on some other thread.

The same race condition exists in set_discard() and set_remove().

Attached is a short script that demonstrates the problem and could be easily converted to a unit test.

----------
components: Interpreter Core
files: set-race.py
messages: 106007
nosy: stutzbach
priority: normal
severity: normal
status: open
title: Race condition when checking for set in set
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17388/set-race.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8757>
_______________________________________

From report at bugs.python.org  Tue May 18 23:46:11 2010
From: report at bugs.python.org (Alex)
Date: Tue, 18 May 2010 21:46:11 +0000
Subject: [issue8758] BUILD_LIST followed by BINARY_SUBSCR can be optimized to
	a BUILD_TUPLE if all members of the list are constants
In-Reply-To: <1274219170.67.0.325819344919.issue8758@psf.upfronthosting.co.za>
Message-ID: <1274219170.67.0.325819344919.issue8758@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

We do the same thing for a BUILD_LIST followed by a COMPARE_OP (in).

----------
components: Interpreter Core
messages: 106008
nosy: alex
priority: normal
severity: normal
status: open
title: BUILD_LIST followed by BINARY_SUBSCR can be optimized to a BUILD_TUPLE if all members of the list are constants
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8758>
_______________________________________

From report at bugs.python.org  Tue May 18 23:57:45 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 18 May 2010 21:57:45 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux;
	totally missing on OSX
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

sridharr at triple:~$ /opt/ActivePython-2.7/bin/python -c "import sys; print sys.path; import cmdln"
['', '/opt/ActivePython-2.7/lib/python27.zip', '/opt/ActivePython-2.7/lib/python2.7', '/opt/ActivePython-2.7/lib/python2.7/plat-linux2', '/opt/ActivePython-2.7/lib/python2.7/lib-tk', '/opt/ActivePython-2.7/lib/python2.7/lib-old', '/opt/ActivePython-2.7/lib/python2.7/lib-dynload', '/home/sridharr/.local/lib/python/2.7/site-packages', '/opt/ActivePython-2.7/lib/python2.7/site-packages']
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named cmdln
sridharr at triple:~$ file /home/sridharr/.local/lib/python2.7/site-packages/cmdln.py 
/home/sridharr/.local/lib/python2.7/site-packages/cmdln.py: a python script text executable


On OSX, I don't even see a ~/.local directory!

python2.7 -c "import sys; print sys.path"
['', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages']

Works as expected on Windows, though.

----------
components: Library (Lib)
messages: 106009
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7: wrong user site directory on Linux; totally missing on OSX
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Wed May 19 00:22:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 22:22:39 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274221359.92.0.480930336412.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The test was introduced by r80066 (issue #7301).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 00:30:53 2010
From: report at bugs.python.org (Orlando Irrazabal)
Date: Tue, 18 May 2010 22:30:53 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>


New submission from Orlando Irrazabal <oirraza at mendoza.gov.ar>:

Build of Python 2.6.5 on AIX 5.3 fails with the below error message.

The configure line is:
./configure 

[...]
building '_multiprocessing' extension
cc_r -qlanglvl=extc89 -DNDEBUG -O -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/sw_install/python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/sw_install/python-2.6.5/Include -I/sw_install/python-2.6.5 -c /sw_install/python-2.6.5/Modules/_multiprocessing/multiprocessing.c -o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/multiprocessing.o
cc_r -qlanglvl=extc89 -DNDEBUG -O -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/sw_install/python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/sw_install/python-2.6.5/Include -I/sw_install/python-2.6.5 -c /sw_install/python-2.6.5/Modules/_multiprocessing/socket_connection.c -o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/socket_connection.o
cc_r -qlanglvl=extc89 -DNDEBUG -O -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -I/sw_install/python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/sw_install/python-2.6.5/Include -I/sw_install/python-2.6.5 -c /sw_install/python-2.6.5/Modules/_multiprocessing/semaphore.c -o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/semaphore.o
./Modules/ld_so_aix cc_r -qlanglvl=extc89 -bI:Modules/python.exp build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/multiprocessing.o build/temp.aix-5./multim3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/socket_connection.o build/temp.aix-5.3-2.6/sw_install/python-2.6.5/Modules/_multiprocessing/semaphore.o -L/usr/local/lib -o build/lib.aix-5.3-2.6/_multiprocessing.so
checking build system type... powerpc-ibm-aix5.3.0.0
checking host system type... powerpc-ibm-aix5.3.0.0
checking target system type... powerpc-ibm-aix5.3.0.0
checking for a BSD-compatible install... /sw_install/python-2.6.5/Modules/_ctypes/libffi/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /sw_install/python-2.6.5/Modules/_ctypes/libffi/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for gcc... cc_r -qlanglvl=extc89
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc_r -qlanglvl=extc89 accepts -g... yes
checking for cc_r -qlanglvl=extc89 option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc_r -qlanglvl=extc89... none
checking dependency style of cc_r -qlanglvl=extc89... none
checking whether cc_r -qlanglvl=extc89 and cc understand -c and -o together... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for non-GNU ld... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking how to run the C preprocessor... cc_r -qlanglvl=extc89 -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... xlC_r
checking whether we are using the GNU C++ compiler... no
checking whether xlC_r accepts -g... yes
checking dependency style of xlC_r... none
checking how to run the C++ preprocessor... xlC_r -E
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 18432
checking command to parse /usr/bin/nm -B output from cc_r -qlanglvl=extc89 object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for cc_r -qlanglvl=extc89 option to produce PIC...
checking if cc_r -qlanglvl=extc89 static flag -bnso -bI:/lib/syscalls.exp works... no
checking if cc_r -qlanglvl=extc89 supports -c -o file.o... yes
checking whether the cc_r -qlanglvl=extc89 linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... aix5.3.0.0 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking for mmap... yes
checking for sys/mman.h... (cached) yes
checking for mmap... (cached) yes
checking whether read-only mmap of a plain file works... yes
checking whether mmap from /dev/zero works... yes
checking for MAP_ANON(YMOUS)... yes
checking whether mmap with MAP_ANON(YMOUS) works... yes
checking for ANSI C header files... (cached) yes
checking for memcpy... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for double... yes
checking size of double... 8
checking for long double... yes
checking size of long double... 8
checking whether byte ordering is bigendian... yes
checking assembler .cfi pseudo-op support... no
checking whether .eh_frame section should be read-only... no
checking for __attribute__((visibility("hidden")))... no
cc_r: 1501-210 command option t contains an incorrect subargument
configure: creating ./config.status
config.status: creating include/ffi.h
sed: Command line is too long.
config.status: creating fficonfig.py
sed: Command line is too long.
config.status: creating fficonfig.h
config.status: linking /sw_install/python-2.6.5/Modules/_ctypes/libffi/src/powerpc/ffitarget.h to include/ffitarget.h
config.status: linking /sw_install/python-2.6.5/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h
config.status: executing depfiles commands
config.status: executing include commands
config.status: executing src commands
Traceback (most recent call last):
  File "./setup.py", line 1919, in <module>
    main()
  File "./setup.py", line 1914, in main
    'Lib/smtpd.py']
  File "/sw_install/python-2.6.5/Lib/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/sw_install/python-2.6.5/Lib/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/sw_install/python-2.6.5/Lib/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/sw_install/python-2.6.5/Lib/distutils/command/build.py", line 134, in run
    self.run_command(cmd_name)
  File "/sw_install/python-2.6.5/Lib/distutils/cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "/sw_install/python-2.6.5/Lib/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "./setup.py", line 201, in build_extensions
    build_ext.build_extensions(self)
  File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "./setup.py", line 234, in build_extension
    if not self.configure_ctypes(ext):
  File "./setup.py", line 1730, in configure_ctypes
    extra_compile_args = fficonfig['ffi_cflags'].split()
KeyError: 'ffi_cflags'
make: 1254-004 The error code from the last command is 1.


Stop.


Thanks.

Orlando

----------
components: Build
messages: 106011
nosy: oirraza
priority: normal
severity: normal
status: open
title: Python 2.6.5 fails to build on AIX 5.3
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Wed May 19 00:59:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 22:59:32 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274223572.77.0.941567317231.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

os.environ is decoded with sys.getfilesystemencoding(), whereas PYTHONWARNINGS is decoded with the locale encoding (locale.getpreferredencoding()) :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 01:27:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 23:27:05 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274225225.11.0.473683675376.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch creates PySys_AddWarnOptionUnicode() function and decodes PYTHONWARNINGS variable with the file system encoding (as it is done for os.environ, to be consistent) instead of the locale encoding.

The patch only concerns the POSIX version. Windows is not affected by this issue (see below).

--

This issue occurs if the file system encoding is different than the locale encoding (especially if the locale encoding is ASCII). It only occurs on Mac OS because on this OS, the file system encoding is hardcoded to UTF-8 whereas the locale encoding... depends on the locale.

I reproduced the bug on Linux by hardcoding the file system encoding to UTF-8.

--

About the test output (UnicodeEncodeError: 'ascii' codec can't encode character '\xf3' ...): I think that Michael Foord executed directly Lib/test/test_warnings.py instead of using "Lib/test/regrtest.py -v test_warnings". I only patched regrtest.py to use backslashreplace error handler on sys.stdout.

----------
keywords: +patch
Added file: http://bugs.python.org/file17389/sys_warnoptions_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 01:35:18 2010
From: report at bugs.python.org (Leonhard Vogt)
Date: Tue, 18 May 2010 23:35:18 +0000
Subject: [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1274225718.38.0.237584135826.issue7447@psf.upfronthosting.co.za>


Leonhard Vogt <leonhard.vogt at gmx.ch> added the comment:

I changed the documentation regarding string not allowed as start argument and performance

I included the list concatenation with itertools.chain from
http://groups.google.com/group/comp.lang.python/msg/33e764d0ac41826a

patch is based on revision 81300 in py3k branch.

----------
keywords: +patch
nosy: +lvogt
Added file: http://bugs.python.org/file17390/functions.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7447>
_______________________________________

From report at bugs.python.org  Wed May 19 01:50:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 May 2010 23:50:23 +0000
Subject: [issue8761] PyUnicode_CompareWithASCIIString name is not mangled
	(UCS2, UCS4)
In-Reply-To: <1274226622.99.0.33307621938.issue8761@psf.upfronthosting.co.za>
Message-ID: <1274226622.99.0.33307621938.issue8761@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In unicodeobject.h, you can see:

# define PyUnicode_CompareWithASCII PyUnicodeUCS2_CompareASCII
...
# define PyUnicode_CompareWithASCII PyUnicodeUCS4_CompareWithASCII
...
PyAPI_FUNC(int) PyUnicode_CompareWithASCIIString(
    PyObject *left,
    const char *right
    );

The defines miss the String suffix :-/

Attached patch adds the suffix but I guess that it breaks backward compatibility. Is it a problem to apply this patch in Python 3.2 (but not in Python 3.1)?

----------
components: Unicode
files: pyunicode_compareascii.patch
keywords: patch
messages: 106015
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_CompareWithASCIIString name is not mangled (UCS2, UCS4)
versions: Python 3.2
Added file: http://bugs.python.org/file17391/pyunicode_compareascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8761>
_______________________________________

From report at bugs.python.org  Wed May 19 02:04:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 00:04:47 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274227487.66.0.618183181823.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81314 fixes 2 calls in _PyModule_Clear().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 02:27:16 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 19 May 2010 00:27:16 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274228836.42.0.0870593328527.issue8729@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Here's a patch that adds test cases.  It exercises all of the following special methods on Set and Mapping to ensure that they return NotImplemented if they don't recognize the other type.

    lt, gt, le, ge, eq, ne, or, and, xor, sub

I made the patch against the py3k branch.

I made the test-case patch separate to make it easier to see the before and after behavior of the actual fix.

----------
Added file: http://bugs.python.org/file17392/eq-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Wed May 19 02:35:35 2010
From: report at bugs.python.org (andrew)
Date: Wed, 19 May 2010 00:35:35 +0000
Subject: [issue8762] default value in constructor not unique across objects
In-Reply-To: <1274229335.16.0.189072837052.issue8762@psf.upfronthosting.co.za>
Message-ID: <1274229335.16.0.189072837052.issue8762@psf.upfronthosting.co.za>


New submission from andrew <atcuno at gmail.com>:

After debugging for a while I finally released that I stumbled across a Python bug (at least I believe it is). Here is a proof of concept that produces the issue:

!/usr/bin/python

class blah:

    def __init__(self, items=[]):
        self.items = items

a = blah()
b = blah()

a.items.append("apples")
b.items.append("oranges")

print a.items
print b.items
print id(a.items)
print id(b.items)


and here is the output when the program is run:

root at x:~# python pythonbug.py
['apples', 'oranges']
['apples', 'oranges']
135923500
135923500
root at x:~#

as you can see the 'items' reference is the same for both objects even though they are different objects. I checked the manual and I couldn't find anything explaining such behavior. Can this possibly be correct?

My python info:

Python 2.5.2 (r252:60911, Jan 20 2010, 21:48:48)

----------
messages: 106018
nosy: bolt
priority: normal
severity: normal
status: open
title: default value in constructor not unique across objects
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8762>
_______________________________________

From report at bugs.python.org  Wed May 19 02:55:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 00:55:04 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274230504.66.0.00814158686003.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81320 fixes a call in vgetargskeywords() (PyArg_ParseTupleAndKeywords).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 03:08:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 01:08:16 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274231296.28.0.195231561227.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81321 fixes 2 calls in builtin_input() (if sys.stdin or sys.stdout encoding contain a surrogate: this is *very* unlikely :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 03:17:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 01:17:23 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274231843.27.0.374907038512.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81322 fixes 2 calls in textio.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 03:27:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 01:27:54 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274232474.66.0.002794798013.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81323 fixes 4 calls in _sqlite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 03:43:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 01:43:07 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274233387.29.0.848267767582.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81324 fixes 2 calls in typeobject.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 03:58:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 01:58:32 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274234312.9.0.800464806106.issue6697@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16461/pythonrun-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 04:00:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 02:00:13 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274234413.79.0.339384635144.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Remove pyunicode_asstringordefault.patch and pythonrun-py3k.patch because the new _PyUnicode_AsStringOrDefault() function was rejected (and it's easy to avoid it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 04:00:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 02:00:19 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274234419.23.0.563909787093.issue6697@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16458/pyunicode_asstringordefault.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 04:01:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 May 2010 02:01:26 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274234486.53.0.451733650499.issue8754@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I refinement would be to only quote when there is whitespace in the name, but I do not know how well that works with unicode versus ascii.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed May 19 04:02:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 May 2010 02:02:12 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274234532.48.0.256315685682.issue8754@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed May 19 04:02:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 May 2010 02:02:28 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274234548.72.0.938561686746.issue8754@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A refinement would be to only quote when there is whitespace in the name, but I do not know how well that works with unicode versus ascii.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed May 19 04:05:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 May 2010 02:05:23 +0000
Subject: [issue8762] default value in constructor not unique across objects
In-Reply-To: <1274229335.16.0.189072837052.issue8762@psf.upfronthosting.co.za>
Message-ID: <1274234723.21.0.333995146303.issue8762@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is not a bug, it's how Python works.  Default values are computed at function definition time, so there's only one list across all the function invocations.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8762>
_______________________________________

From report at bugs.python.org  Wed May 19 04:05:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 02:05:29 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1274234729.23.0.58657150502.issue8070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

tlesher> If you don't have time to update the patch, let me know and I'll put one together.

I would be happy if you write a new patch :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8070>
_______________________________________

From report at bugs.python.org  Wed May 19 04:08:06 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 19 May 2010 02:08:06 +0000
Subject: [issue8762] default value in constructor not unique across objects
In-Reply-To: <1274229335.16.0.189072837052.issue8762@psf.upfronthosting.co.za>
Message-ID: <1274234886.79.0.669424449161.issue8762@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Here is the explanation from Python Language Reference 7.6: Function Definitions
"""
When one or more top-level parameters have the form parameter = expression, the function is said to have ``default parameter values.'' For a parameter with a default value, the corresponding argument may be omitted from a call, in which case the parameter's default value is substituted. If a parameter has a default value, all following parameters must also have a default value -- this is a syntactic restriction that is not expressed by the grammar. 
Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that that same ``pre-computed'' value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function, e.g.: 

def whats_on_the_telly(penguin=None):
    if penguin is None:
        penguin = []
    penguin.append("property of the zoo")
    return penguin
"""

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8762>
_______________________________________

From report at bugs.python.org  Wed May 19 04:29:44 2010
From: report at bugs.python.org (Michele)
Date: Wed, 19 May 2010 02:29:44 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1274236184.11.0.212774454589.issue7946@psf.upfronthosting.co.za>


Michele <vo.sinh at gmail.com> added the comment:

Attached ccbench-osx.log made today on OSX on latest svn checkout. Hope it helps

----------
nosy: +Michele
Added file: http://bugs.python.org/file17393/ccbench-osx.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed May 19 05:48:27 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Wed, 19 May 2010 03:48:27 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1274240907.06.0.836276192736.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I tried to understand the cause of failures and I don't see how test_pdb2 could have caused them ;-).

Here is the relevant part of buildbot timeline:

http://www.python.org/dev/buildbot/trunk/?last_time=1273368351&show_time=7400

The only test failures which have  log files were sparc solaris 10 and ia64 and both failures were in test_unittest. All other buildbot failures don't have test logs associated with them..

Is there a way to  access test logs for other platforms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Wed May 19 06:18:28 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:18:28 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242708.86.0.829513650778.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 3.2 branch.

----------
keywords: +patch
nosy: +efm
Added file: http://bugs.python.org/file17394/telnetlib3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Wed May 19 06:19:31 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:19:31 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242771.9.0.358507681754.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 2.6 branch

----------
Added file: http://bugs.python.org/file17395/telnetlib2.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Wed May 19 06:20:10 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:20:10 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242810.49.0.852876607497.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 2.7 branch

----------
Added file: http://bugs.python.org/file17396/telnetlib2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Wed May 19 06:20:47 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:20:47 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242847.1.0.969098530855.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 3.1 branch

----------
Added file: http://bugs.python.org/file17397/telnetlib3.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Wed May 19 07:28:51 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 May 2010 05:28:51 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1274246931.53.0.416495738287.issue8754@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It wouldn't matter (at least in Python 3) as str is unicode-aware. It's more about whether it's worth special-casing the output. I say no and just go with using the repr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed May 19 07:58:50 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 May 2010 05:58:50 +0000
Subject: [issue8750] Many of MutableSet's methods assume that the other
	parameter is not self
In-Reply-To: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>
Message-ID: <1274248730.52.0.865151616947.issue8750@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Here's a possible fix:

def __isub__(self, it):
    if it is self:
        self.clear()
    else:
        for value in it:
            self.discard(value)
    return self

----------
nosy: +rhettinger
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8750>
_______________________________________

From report at bugs.python.org  Wed May 19 08:06:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 May 2010 06:06:18 +0000
Subject: [issue3051] heapq change breaking compatibility
In-Reply-To: <1212755858.43.0.854603033808.issue3051@psf.upfronthosting.co.za>
Message-ID: <1274249178.78.0.59224973723.issue3051@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For what it's worth, I agree with Fijal.  I think the python version and the C version should behave the same, so that other implementations of Python can use the Python version and be compatible wtih CPython.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3051>
_______________________________________

From report at bugs.python.org  Wed May 19 08:24:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 May 2010 06:24:00 +0000
Subject: [issue8761] PyUnicode_CompareWithASCIIString name is not mangled
	(UCS2, UCS4)
In-Reply-To: <1274226622.99.0.33307621938.issue8761@psf.upfronthosting.co.za>
Message-ID: <1274250240.99.0.590848324684.issue8761@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's fine to apply to 3.2.

----------
nosy: +loewis
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8761>
_______________________________________

From report at bugs.python.org  Wed May 19 11:05:17 2010
From: report at bugs.python.org (Christophe Simonis)
Date: Wed, 19 May 2010 09:05:17 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1274259917.74.0.00425694854063.issue444582@psf.upfronthosting.co.za>


Changes by Christophe Simonis <simonis.christophe at gmail.com>:


----------
nosy: +Christophe Simonis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Wed May 19 11:20:45 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 19 May 2010 09:20:45 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
	PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1274260845.7.0.450206172157.issue8070@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8070>
_______________________________________

From report at bugs.python.org  Wed May 19 12:01:29 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 10:01:29 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1274263289.86.0.680828841246.issue8721@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I couldn't find the relevant commits, but if we didn't do it, ISTM that we should backport the fix in the next 2.6 so it behaves like in 2.7.

----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Wed May 19 12:13:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 19 May 2010 10:13:10 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1274263990.59.0.0878792000069.issue8721@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

tarek: Issue2987 has the details on changes made for ipv6 urlparse.
Those can't be backported as it's a feature. I would rather like to see whats breaking in distutils2. 

The url which resulted in this bug in distribute: "http://www.famfamfam.com](http://www.famfamfam.com/" is clearly an invalid one. What can be done is py26, looking for invalid char like '[' or ']' outside of netloc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Wed May 19 12:19:51 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 19 May 2010 10:19:51 +0000
Subject: [issue8763] py3K bdist_msi wrongly installs itself in ALL python
	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

I've created a pure-python package with py3k's bdist_msi, and weirdly, even though the windows installer asks for the target directory, it installs the package in ALL python distributions installed (py26, py27 and py31), which is particularly embarassing since it's a py3k-only pure-python package...

----------
assignee: tarek
components: Distutils
files: RSFile-1.0.win32.msi
messages: 106042
nosy: pakal, tarek
priority: normal
severity: normal
status: open
title: py3K bdist_msi wrongly installs itself in ALL python versions
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17398/RSFile-1.0.win32.msi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8763>
_______________________________________

From report at bugs.python.org  Wed May 19 12:56:44 2010
From: report at bugs.python.org (davy zhang)
Date: Wed, 19 May 2010 10:56:44 +0000
Subject: [issue8764] logging RotatingFileHandler cause too long to fininsh
In-Reply-To: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>
Message-ID: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>


New submission from davy zhang <davyzhang at gmail.com>:

the function below is used to determine the proper file name of the next log file. But the question is if I set a large number of self.backupCount like 10000000, it will take too long to calculate the right file name. I think it could be a better way to do this instead of finding from the end.

    def doRollover(self):
        """
        Do a rollover, as described in __init__().
        """

        self.stream.close()
        if self.backupCount > 0:
            for i in range(self.backupCount - 1, 0, -1):
                sfn = "%s.%d" % (self.baseFilename, i)
                dfn = "%s.%d" % (self.baseFilename, i + 1)
                if os.path.exists(sfn):
                    #print "%s -> %s" % (sfn, dfn)
                    if os.path.exists(dfn):
                        os.remove(dfn)
                    os.rename(sfn, dfn)
            dfn = self.baseFilename + ".1"
            if os.path.exists(dfn):
                os.remove(dfn)
            os.rename(self.baseFilename, dfn)
            #print "%s -> %s" % (self.baseFilename, dfn)
        self.mode = 'w'
        self.stream = self._open()

----------
messages: 106043
nosy: davy.zhang
priority: normal
severity: normal
status: open
title: logging RotatingFileHandler cause too long to fininsh
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8764>
_______________________________________

From report at bugs.python.org  Wed May 19 12:58:25 2010
From: report at bugs.python.org (davy zhang)
Date: Wed, 19 May 2010 10:58:25 +0000
Subject: [issue8764] logging RotatingFileHandler cause too long to fininsh
In-Reply-To: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>
Message-ID: <1274266705.15.0.571614024265.issue8764@psf.upfronthosting.co.za>


Changes by davy zhang <davyzhang at gmail.com>:


----------
components: +Library (Lib)
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8764>
_______________________________________

From report at bugs.python.org  Wed May 19 13:15:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 May 2010 11:15:12 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux;
	totally missing on OSX
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274267712.1.0.238922027893.issue8759@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
nosy: +ronaldoussoren, tarek
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Wed May 19 13:20:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 May 2010 11:20:36 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1274268036.98.0.607189571317.issue444582@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Wed May 19 13:22:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 May 2010 11:22:22 +0000
Subject: [issue8764] logging RotatingFileHandler cause too long to fininsh
In-Reply-To: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>
Message-ID: <1274268142.09.0.0376345288283.issue8764@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8764>
_______________________________________

From report at bugs.python.org  Wed May 19 13:33:23 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 11:33:23 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux;
	totally missing on OSX
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274268803.46.0.591406580357.issue8759@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Are you sure you didn't deactivate use site ? (by turning site.ENABLE_USER_SITE off)

Please check its value:

  >>> import site
  >>> site.ENABLE_USER_SITE 
  True


Pathes look fine on my Mac : 

Python 2.7b2+ (trunk:81228, May 16 2010, 14:42:34) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.7/site-packages/pip-0.6.1-py2.7.egg', '/usr/local/lib/python2.7/site-packages/distribute-0.6.11dev-py2.7.egg', '/usr/local/lib/python27.zip', '/MacDev/svn.python.org/python-trunk/Lib', '/MacDev/svn.python.org/python-trunk/Lib/plat-darwin', '/MacDev/svn.python.org/python-trunk/Lib/plat-mac', '/MacDev/svn.python.org/python-trunk/Lib/plat-mac/lib-scriptpackages', '/MacDev/svn.python.org/python-trunk/Lib/lib-tk', '/MacDev/svn.python.org/python-trunk/Lib/lib-old', '/MacDev/svn.python.org/python-trunk/build/lib.macosx-10.4-i386-2.7', '/Users/tarek/.local/lib/python/2.7/site-packages', '/usr/local/lib/python2.7/site-packages']


If you still have the issue, you need to trace python load in site.py, where all the paths are added, by printing them out for example, and using the -v flag

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Wed May 19 13:33:29 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 19 May 2010 11:33:29 +0000
Subject: [issue8763] py3K bdist_msi wrongly installs itself in ALL python
	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274268809.61.0.811157459797.issue8763@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Could you attach the source to a small example? I don't think anyone's interested in running a random .msi file.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8763>
_______________________________________

From report at bugs.python.org  Wed May 19 13:35:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 11:35:11 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1274268911.41.0.384984346383.issue444582@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

SOunds like a good feature to add in shutil, I'll check the patch and also compare it to distutils.spawn.find_executable()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Wed May 19 13:47:24 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 May 2010 11:47:24 +0000
Subject: [issue8733] list type and UserList do not call super in __init__ and
	therefore, they cannot be parents in a multiple inheritence scheme
In-Reply-To: <1274269644.21.0.524799705686.issue8733@psf.upfronthosting.co.za>
Message-ID: <1274269644.21.0.524799705686.issue8733@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Why does it matter? They both inherit from object, so there's no one to pass parameters to.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8733>
_______________________________________

From report at bugs.python.org  Wed May 19 13:55:46 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 19 May 2010 11:55:46 +0000
Subject: [issue8763] py3K bdist_msi wrongly installs itself in ALL python
	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274270146.84.0.654072560845.issue8763@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Thansk for the attention,

Here it is (I ran bdist_msi with the latest SVN py3k version).

----------
Added file: http://bugs.python.org/file17399/RSFile-1.0.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8763>
_______________________________________

From report at bugs.python.org  Wed May 19 13:56:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 11:56:24 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1274270184.25.0.279480262765.issue8663@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17342/distutils_spawn_log.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 14:00:09 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 12:00:09 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1274270409.81.0.670483229688.issue8721@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Senthil: thx for the pointer. 

I've fixed the problem on distribute side by catching any ValueError returned by urlparse (from 2.6 or 2.7 point of view).

That said, I don't think than catching more invalid URLs in Python 2.7 should be considered as a feature. 

If it's a new feature then we should have an option to explicitly parse IpV6-like URLs and leave the default behavior like it was in 2.6. If not, then it should be considered as a bug fix (meaning that Python now discards more malformed URLs) and should be backported imo.

IOW, I want to discard invalid URLs the same way no matter what the Python version is, because this is not a rule defined by Python, rather by some RFCs at the URL level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Wed May 19 14:03:24 2010
From: report at bugs.python.org (Christophe Combelles)
Date: Wed, 19 May 2010 12:03:24 +0000
Subject: [issue8740] infinite recursion with setfilesystemencoding and pdb
In-Reply-To: <1274103951.28.0.0596224885808.issue8740@psf.upfronthosting.co.za>
Message-ID: <1274270604.26.0.004728059606.issue8740@psf.upfronthosting.co.za>


Christophe Combelles <ccomb at free.fr> added the comment:

(I forgot to mention that the bug occured on python 3.1.2.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8740>
_______________________________________

From report at bugs.python.org  Wed May 19 14:03:45 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 12:03:45 +0000
Subject: [issue8763] py3K bdist_msi wrongly installs itself in ALL python
	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274270625.23.0.86583710819.issue8763@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

did you use any particular option when running it ?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8763>
_______________________________________

From report at bugs.python.org  Wed May 19 14:16:55 2010
From: report at bugs.python.org (=?utf-8?q?Greg_S=C5=82odkowicz?=)
Date: Wed, 19 May 2010 12:16:55 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't work
	on OS X Snow Leopard
In-Reply-To: <1261886525.19.0.539991282646.issue7580@psf.upfronthosting.co.za>
Message-ID: <1274271415.66.0.648495228853.issue7580@psf.upfronthosting.co.za>


Greg S?odkowicz <jergosh at gmail.com> added the comment:

Doesn't breaking installation of packages on a major platform warrant a quicker release of a fix?

----------
nosy: +Greg.Slodkowicz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Wed May 19 14:17:56 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 19 May 2010 12:17:56 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

In test_fileio, one of the tests wants to ensure writing to closed raw streams fails, but it actually tries to write an unicode string, which should rather lead to an immediate TypeError.

Here is a tiny patch to prevent the "double error cause" danger - this test is bugging me because my own I/O library cant pass the stdlib io tests in this case.

The initial problem here is that we can't write unicode to a buffered binary stream (TypeError), but we can do it with an unbufferred raw stream - as the C implementation of the latter does string coercion instead of raising TypeError.
Shouldn't we unify the behaviour of binary streams in such cases ?

----------
components: IO
files: test_fileio_errclosedonwrite.patch
keywords: patch
messages: 106053
nosy: pakal
priority: normal
severity: normal
status: open
title: Tests unwillingly writing unicocde to raw streams
versions: Python 2.7
Added file: http://bugs.python.org/file17400/test_fileio_errclosedonwrite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Wed May 19 14:28:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 May 2010 12:28:51 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274272131.8.0.536972457963.issue8765@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Wed May 19 14:32:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 12:32:20 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274272340.47.0.998333628311.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

tarek tested on Mac OS X: the patch fixes test_warnings issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 14:38:58 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 12:38:58 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1274272738.52.0.181465551659.issue444582@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@iki: could you refactor your code so it's in shutil (and the tests in test_shutil)

few remarks: only which/which_files should be public API,

Next, I don't think extensions like VBS should be hardcoded if PATHEXT is not found. A pseudo-dos shell just runs .exe and .com IIRC, if not, there's probably somewhere in the win32 environment a list of extensions and their associated programs that get called automatically from the shell (in addition to PATHEXT). We need to find this list programatically rather that harcoding a list that will change from one box to the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Wed May 19 14:41:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 12:41:59 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1274272919.38.0.262084100484.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Although, all these patchs should have some tests demonstrating the bugs

As discussed on IRC, fixing distutils.log package instead of setup.py is better. New patch includes unit tests.

----------
Added file: http://bugs.python.org/file17401/distutils_log_backslashreplace-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 14:51:55 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 19 May 2010 12:51:55 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux;
	totally missing on OSX
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274273515.37.0.742065613751.issue8759@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The --user directory for framework installs of python on OSX has changed from a subdirectory of ~/.local to a subdirectory ~/Library. As described in the NEWS file:

- Issue #8084: PEP 370 now conforms to system conventions for framework
  builds on MacOS X. That is, "python setup.py install --user" will install
  into "~/Library/Python/2.7" instead of "~/.local".


In python 2.6 both ~/.local and ~/Library/Python were added to sys path and that's confusing. As ~/.local does not conform to the filesystem layout conventions on OSX the --user directory now always refers to ~/Library/Python.

For classic unix installs --user still uses the unix conventions. I'm not 100% sure that that is the right choice.


In other words: works as designed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Wed May 19 15:04:43 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 19 May 2010 13:04:43 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1274274283.91.0.643731092084.issue6697@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

r81319 fixed 4 calls in pythonrun.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed May 19 15:14:02 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 19 May 2010 13:14:02 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274274842.07.0.623660694228.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> For a complex number z and an integer i, 'z == i' should be exactly 
> equivalent to 'z.real == i and z.imag == 0.0'.

Like you mentioned before a lot of care is taken in 'floatobject.c' to ensure that the comparison is robust.  Would it be a good approach to leverage that work?

I have attached a patch with that idea.  If it seems reasonable, then I can clean it up and add more tests.  I created the patch for py3k.  I think the 2.x changes will be slightly different due to the coercion aspects.

One of the unit tests ('test_complex.test_richcompare') explicitly checks for the overflow.  However, the approach of just having the comparison return 'False' in these cases is more robust.  Is there any use case for explicitly notifying of overflow with comparisons?  It seems like more of an implementation artifact to me...

----------
keywords: +patch
nosy: +minge
Added file: http://bugs.python.org/file17402/issue-8748.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Wed May 19 15:15:43 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 19 May 2010 13:15:43 +0000
Subject: [issue8763] py3K bdist_msi wrongly installs itself in ALL python
	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274274943.52.0.0158149502833.issue8763@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

None at all, a simple python "setup.py bdist_msi".

Once I've installed the MSI(and whatever the target python version I chose), launching it again will always trigger a "repair/uninstall" wizard, and the operatiosn I do with it are made on ALL python versions at teh same time (eg., if I uninstall, my library gets properly removed from ALL site-packages directories....).

That's really weird actually, I've not found mentions of similar errors on the web or bug tracker...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8763>
_______________________________________

From report at bugs.python.org  Wed May 19 15:19:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 19 May 2010 13:19:11 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1274275151.95.0.102197625163.issue8142@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It seems fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Wed May 19 15:20:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 13:20:42 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274275242.48.0.44004996784.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Like you mentioned before a lot of care is taken in 'floatobject.c' to > ensure that the comparison is robust.  Would it be a good approach to
> leverage that work?

Absolutely, yes!  I was thinking of moving that chunk of code out of float_richcompare and into something like _PyLong_CompareWithDouble (in Objects/longobject.c).  Then it can be used by both float_richcompare and complex_richcompare.

Hmm.  This works well for py3k, but not so well for trunk, where we have to deal with plain 'int's as well.

I'd definitely like this fixed in 2.7 and 3.2:  it's horrible behaviour.  I'm still wondering about 2.6 and 3.1.  I just discovered that there's actually a test for part of this behaviour (first line of test_richcompare in test_complex.py):

    self.assertRaises(OverflowError, complex.__eq__, 1+1j, 1<<10000)

Nevertheless, I still maintain that this is wrong:  raising an exception in __eq__ is always a dangerous thing to do for hashable objects, since it leads to confusing behavour like this:
Python 2.5.1 (r251:54863, Dec 6 2008, 10:49:39)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = set([2**1024])
>>> s.add(complex(0))
>>> s.add(complex(2))
>>> s.add(complex(1))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Wed May 19 15:21:16 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 May 2010 13:21:16 +0000
Subject: [issue8764] logging RotatingFileHandler cause too long to fininsh
In-Reply-To: <1274266604.24.0.270763712229.issue8764@psf.upfronthosting.co.za>
Message-ID: <1274275276.88.0.834759459559.issue8764@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

If you look closely, the system is not determining the name of the next log file. It is renaming log files - app.log.2 -> app.log.3, app.log.1 -> app.log.2, app.log -> app.log.1. The "next log file" is always app.log (or whatever the base file name is, I've just used app.log as an example).

It doesn't make sense to set a very large backupCount value, say of ten million (as in your example); why would you want to do this? Did you perhaps mean 10,000,000 for the maxBytes value? If you did mean backupCount, and if you do have a valid reason, then you can subclass this handler and write your own rollover implementation which does whatever you want.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8764>
_______________________________________

From report at bugs.python.org  Wed May 19 15:22:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 13:22:00 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274275320.19.0.271238472718.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thinking about it, I still like the _PyLong_CompareWithDouble plan even for trunk:  there's a precedent for some PyLong methods working with plain ints as well as for longs.  See e.g. PyLong_AsLongLong and friends.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Wed May 19 15:26:05 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 19 May 2010 13:26:05 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1274275565.52.0.797311649443.issue7902@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Does this patch seem reasonable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7902>
_______________________________________

From report at bugs.python.org  Wed May 19 15:27:22 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 19 May 2010 13:27:22 +0000
Subject: [issue8766] Segmentation fault with empty "encodings" subdirectory of
	directory in PYTHONPATH
In-Reply-To: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>
Message-ID: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python 3.1 and 3.2 fail with segmentation fault when a directory in PYTHONPATH contains an empty "encodings" subdirectory.

$ cd /tmp 
$ mkdir encodings
$ PYTHONPATH=. python3.1
Segmentation fault

----------
components: Interpreter Core, Unicode
messages: 106066
nosy: Arfrever, haypo
priority: normal
severity: normal
status: open
title: Segmentation fault with empty "encodings" subdirectory of directory in PYTHONPATH
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8766>
_______________________________________

From report at bugs.python.org  Wed May 19 15:27:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 May 2010 13:27:31 +0000
Subject: [issue1053369] ftplib: add support for MDTM command
Message-ID: <1274275651.5.0.166219430908.issue1053369@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Closing this out for lack of further activity.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1053369>
_______________________________________

From report at bugs.python.org  Wed May 19 15:30:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 13:30:11 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274275811.12.0.143822194329.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Meador]
> One of the unit tests ('test_complex.test_richcompare') explicitly
> checks for the overflow.

[Mark]
> I just discovered that there's actually a test for part of this
> behaviour

D'oh!  Next time I'll read your whole message before responding to the first bit.  Apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Wed May 19 15:30:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 May 2010 13:30:42 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274275842.76.0.09496449025.issue8760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

According to your log, the interpreter itself compiled fine (you can check that with "./python" and even run the test suite: "./python -m test.regrtest -w"), but the _ctypes extension failed configuring.

----------
assignee:  -> theller
nosy: +pitrou, theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Wed May 19 15:40:30 2010
From: report at bugs.python.org (Sagiv Malihi)
Date: Wed, 19 May 2010 13:40:30 +0000
Subject: [issue8733] list type and UserList do not call super in __init__ and
	therefore, they cannot be parents in a multiple inheritence scheme
In-Reply-To: <1274269644.21.0.524799705686.issue8733@psf.upfronthosting.co.za>
Message-ID: <1274276430.53.0.00268645985613.issue8733@psf.upfronthosting.co.za>


Sagiv Malihi <sagivmalihi at gmail.com> added the comment:

Example:

class A(object):
 def __init__(self):
  print "initializing something very important"
  # and then pay it forward...
  super(A, self).__init__()

class B(list, A): pass

b = B()
# A's init is never called...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8733>
_______________________________________

From report at bugs.python.org  Wed May 19 15:42:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 13:42:12 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274276532.07.0.655828387318.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

>From a brief glance, the approach in your patch looks fine to me.  I'll have a proper look at it later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Wed May 19 15:44:04 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 May 2010 13:44:04 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1274276644.69.0.359631135937.issue6589@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Could you provide an actual example code which reproduces this problem?
It's not clear to me how the dispatcher instance can end up in an "invalid state" since handle_error() should automatically remove the "invalid dispatcher instance" from the socket_map if anything unexpected happens.
If this doesn't happen it might be a problem related with what you've in your subclass (e.g. you have overridden handle_error and avoided to call close() yourself).

Furthermore the use case you have described it's pretty uncommon as you shouldn't run SMTPServer in a thread in the first place.

If you intend to bind two servers simultaneously you just have to instantiate two STMPServer sub/classes and finally call asyncore.loop().
Both instances will automatically be served by asyncore itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed May 19 15:50:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 May 2010 13:50:11 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1274277011.44.0.429342355393.issue6589@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed May 19 15:50:53 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 May 2010 13:50:53 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1274277053.66.0.253583843522.issue6589@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Could you provide an actual example code which reproduces this problem?
It's not clear to me how the dispatcher instance can end up in an "invalid state" since handle_error() should automatically remove the invalid dispatcher instance from the socket_map if anything unexpected happens.
If this doesn't happen it might be a problem related with what you've done in your subclass (e.g. you have overridden handle_error and avoided to call close() yourself).

Furthermore the use case you have described it's pretty uncommon as you shouldn't run SMTPServer in a thread in the first place.

If you intend to bind two servers simultaneously you just have to instantiate two STMPServer sub/classes and finally call asyncore.loop().
Both instances will automatically be served by asyncore itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Wed May 19 16:00:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 19 May 2010 14:00:35 +0000
Subject: [issue8763] py3K bdist_msi wrongly installs itself in ALL python
	versions
In-Reply-To: <1274264391.85.0.389216005018.issue8763@psf.upfronthosting.co.za>
Message-ID: <1274277635.02.0.277851990794.issue8763@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Are you allowing it to install into all Python versions? I have a package here at work that I make bdist_msi installers for and most of my machines have 2.6 and 3.1 on them. During the install I only choose to install it for 3.1 when the extensions are compiled for that version, and it does not end up getting installed to the 2.6 area (or vice versa).

This is what I choose during the install, which ends up working properly: http://i.imgur.com/vq5ch.png (safe link, it's an image uploading site)

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8763>
_______________________________________

From report at bugs.python.org  Wed May 19 18:08:31 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 19 May 2010 16:08:31 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1274270409.81.0.670483229688.issue8721@psf.upfronthosting.co.za>
Message-ID: <0228117B-824E-490A-B4C7-77DA997A15C4@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-05-19, at 5:00 AM, Tarek Ziad? wrote:

> I've fixed the problem on distribute side by catching any ValueError returned by urlparse (from 2.6 or 2.7 point of view).

Catching ValueError will catch *every* ValueError raised, rather than only the intended one: ValueError("Invalid IPv6 URL"). Can we have a custom exception for this? Generally, I am curious as to what the convention is in regards to raising standard vs custom exceptions from the standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Wed May 19 18:21:55 2010
From: report at bugs.python.org (Charles Solar)
Date: Wed, 19 May 2010 16:21:55 +0000
Subject: [issue8767] Configure: Cannot disable unicode
In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za>
Message-ID: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za>


New submission from Charles Solar <charlessolar at gmail.com>:

I am compiling python on AIX 5.3.  The normal configure and make works, except it fails to compile the unicodedata module.  The assembler reports a bunch of these errors:
Error: value of 000000000001268b too large for field of 2 bytes at 000000000000006d

The module is labeled as optional, but if that one fails python will not install.  One of the .py files it tries to compile requires unicodedata so the whole thing fails.

I tried --enable-unicode=ucs4 and got the same results so then I tried just --disable-unicode all together and configure spits out: 
checking what type to use for unicode... configure: error: invalid value for --enable-unicode. Use either ucs2 or ucs4 (lowercase).

I had to go into the configure script itself remove a default case statement that produced the error to disable it completely.

Building Python2.7b1 on AIX 5.3

----------
components: Build
files: config.log
messages: 106076
nosy: redcomet
priority: normal
severity: normal
status: open
title: Configure: Cannot disable unicode
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file17403/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8767>
_______________________________________

From report at bugs.python.org  Wed May 19 18:32:30 2010
From: report at bugs.python.org (Charles Solar)
Date: Wed, 19 May 2010 16:32:30 +0000
Subject: [issue8767] Configure: Cannot disable unicode
In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za>
Message-ID: <1274286750.56.0.0950339805496.issue8767@psf.upfronthosting.co.za>


Charles Solar <charlessolar at gmail.com> added the comment:

Seems as though python 2.7 should not support --disable-unicode so this ticket is invalid.  I just googled python disable unicode, but it seems that the decision to never disable unicode is recent.
Closing

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8767>
_______________________________________

From report at bugs.python.org  Wed May 19 18:32:50 2010
From: report at bugs.python.org (Charles Solar)
Date: Wed, 19 May 2010 16:32:50 +0000
Subject: [issue8767] Configure: Cannot disable unicode
In-Reply-To: <1274286115.56.0.588868311562.issue8767@psf.upfronthosting.co.za>
Message-ID: <1274286770.46.0.0331908990722.issue8767@psf.upfronthosting.co.za>


Changes by Charles Solar <charlessolar at gmail.com>:


Removed file: http://bugs.python.org/file17403/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8767>
_______________________________________

From report at bugs.python.org  Wed May 19 18:46:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 16:46:57 +0000
Subject: [issue8766] Segmentation fault with empty "encodings" subdirectory of
	directory in PYTHONPATH
In-Reply-To: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>
Message-ID: <1274287617.97.0.156110792553.issue8766@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is that a warning is emited before the _warnings module is initialized: get_filter() uses _filters which is equal to NULL.

Attached patch initialize the _warnings module (but not the warnings module) before initfsencoding(). initfsencoding() is the first function loading modules (especially the encoding package) and so _warnings have to be initialized before.

The patch does also fix get_filter() to avoid the crash. This fix alone is not enough to fix this issue: Python cannot start because PyErr_WarnEx() returns -1 if _warnings is not initialized yet.

I tried to display the warning (Not importing directory '/tmp/encodings': missing __init__.py) but it looks to be impossible: display a warning requires that warnings is loaded, but import warnings emits the warning. warnings imports indirectly encodings (linecache -> tokenize -> codecs). I consider that avoiding the crash is enough :-)

--

The encodings can be not empty: the crash occurs if there is an encoding directory is sys.path without the __init__.py file.


   $ mkdir encodings
   $ touch encodings/a
   $ touch encodings/b
   $ touch encodings/c
   $ PYTHONPATH=$PWD ./python 
   Erreur de segmentation

----------
keywords: +patch
Added file: http://bugs.python.org/file17404/warnings_bootstrap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8766>
_______________________________________

From report at bugs.python.org  Wed May 19 18:54:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 16:54:16 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274288056.28.0.593221041858.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, I commited my patch: r81358 (py3k). I'm waiting for the buildbots before backporting the fix to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 18:54:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 16:54:35 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274288075.27.0.500806031686.issue8589@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 18:55:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 19 May 2010 16:55:00 +0000
Subject: [issue8768] The checkempty_symmetric_difference test is never called
In-Reply-To: <1274288100.9.0.0116762037364.issue8768@psf.upfronthosting.co.za>
Message-ID: <1274288100.9.0.0116762037364.issue8768@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In test_set.py (and test_sets.py in 2.x), there's a method named "checkempty_symmetric_difference".  It should be named "test_checkempty_symmetric_difference" so that it will actually be called as a test.  It's not referenced anywhere else.

The test verifies the XOR identity: some_set == some_set ^ empty_set.

Patch against trunk attached.

----------
components: Tests
files: missing-test.patch
keywords: patch
messages: 106080
nosy: stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: The checkempty_symmetric_difference test is never called
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17405/missing-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8768>
_______________________________________

From report at bugs.python.org  Wed May 19 18:58:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 16:58:32 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274288312.01.0.172623138585.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, this patch looks fine to me for py3k.  More tests would be great, but I don't see much other cleaning up that needs doing.

Just one thing:  I'd make the 'i.imag == 0.0' check earlier, so that the potentially expensive long-to-float check can be avoided where appropriate.

I'd also move the 'op != Py_EQ && op != Py_NE' check before the first TO_COMPLEX, though I realize that this is orthogonal to the issue under discussion;  the definition seems cleaner that way, though I don't think it makes any difference to the behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Wed May 19 19:00:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 17:00:46 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1274288446.07.0.821677539292.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited to patch on distutils.log in r81359 (py3k). I'm waiting for the buildbot before backporting to 3.1.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 19:03:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 May 2010 17:03:47 +0000
Subject: [issue8721] urlparse.urlsplit regression in 2.7
In-Reply-To: <1273890533.08.0.00904803911562.issue8721@psf.upfronthosting.co.za>
Message-ID: <1274288627.63.0.787256134048.issue8721@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why would you not want to catch all value errors?  I assume (perhaps a bad thing) that distribute will repeat the returned error message in a more user friendly format.  If a bug in urlparse returns a spurious ValueError, that will presumably be found (and then corrected) either by the test suite or by other code in addition to distribute.

The standard library should use standard exceptions unless there is a compelling reason to create a new exception.  This rule of thumb has not always been followed, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8721>
_______________________________________

From report at bugs.python.org  Wed May 19 19:08:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 May 2010 17:08:07 +0000
Subject: [issue7580] distutils makefile from python.org installer doesn't
	work	on OS X Snow Leopard
In-Reply-To: <1274271415.66.0.648495228853.issue7580@psf.upfronthosting.co.za>
Message-ID: <4BF41AF3.5040907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Doesn't breaking installation of packages on a major platform warrant a quicker release of a fix?

No, only security-related issues may warrant a change to the release
schedule.

----------
title: distutils makefile from python.org installer doesn't work on OS X Snow Leopard -> distutils makefile from python.org installer doesn't work	on OS X Snow Leopard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7580>
_______________________________________

From report at bugs.python.org  Wed May 19 19:21:23 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 19 May 2010 17:21:23 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274289683.99.0.656797305142.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Removed file: http://bugs.python.org/file17385/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Wed May 19 19:22:24 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 19 May 2010 17:22:24 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274289744.08.0.506799598119.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Added file: http://bugs.python.org/file17406/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Wed May 19 19:48:49 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 19 May 2010 17:48:49 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274291329.22.0.686834448732.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Added file: http://bugs.python.org/file17407/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Wed May 19 19:49:01 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 19 May 2010 17:49:01 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274291341.04.0.927248961547.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Removed file: http://bugs.python.org/file17406/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Wed May 19 19:54:43 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 19 May 2010 17:54:43 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274291683.62.0.338123332422.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Removed file: http://bugs.python.org/file17407/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Wed May 19 19:55:01 2010
From: report at bugs.python.org (Dan Buch)
Date: Wed, 19 May 2010 17:55:01 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1274291701.79.0.266512982417.issue8591@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Added file: http://bugs.python.org/file17408/mkpkg-round-of-pylinting.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8591>
_______________________________________

From report at bugs.python.org  Wed May 19 19:58:42 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 19 May 2010 17:58:42 +0000
Subject: [issue8687] sched.py module doesn't have a test suite
In-Reply-To: <1273580886.01.0.152818867035.issue8687@psf.upfronthosting.co.za>
Message-ID: <1274291922.32.0.529249684083.issue8687@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8687>
_______________________________________

From report at bugs.python.org  Wed May 19 20:08:40 2010
From: report at bugs.python.org (Ashley Sands)
Date: Wed, 19 May 2010 18:08:40 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1274292520.41.0.730164585222.issue8667@psf.upfronthosting.co.za>


Ashley Sands <ashley.j.sands at gmail.com> added the comment:

Thanks Senthil & Brett for your help.

Here's my patch. It is very simple, so simple I think it may be wrong.

----------
keywords: +patch
Added file: http://bugs.python.org/file17409/linkToPep3247.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Wed May 19 20:27:11 2010
From: report at bugs.python.org (Orlando Irrazabal)
Date: Wed, 19 May 2010 18:27:11 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274275842.76.0.09496449025.issue8760@psf.upfronthosting.co.za>
Message-ID: <4BF42D76.7040909@mendoza.gov.ar>


Orlando Irrazabal <oirraza at mendoza.gov.ar> added the comment:

Antonie, you are right, the interpreter was compiled fine, this is the 
output when i run python

root at host:python-2.6.5# ./python
'import site' failed; use -v for traceback
Python 2.6.5 (r265:79063, May 18 2010, 19:19:48) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
 >>>

but when i run ./python -m test.regrtest -w , the output is:
root at host:python-2.6.5# ./python -m test.regrtest -w
'import site' failed; use -v for traceback
Could not import runpy module

Thanks

Orlando Irrazabal
El 19/05/2010 10:30, Antoine Pitrou escribi?:
> Antoine Pitrou<pitrou at free.fr>  added the comment:
>
> According to your log, the interpreter itself compiled fine (you can check that with "./python" and even run the test suite: "./python -m test.regrtest -w"), but the _ctypes extension failed configuring.
>
> ----------
> assignee:  ->  theller
> nosy: +pitrou, theller
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8760>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Wed May 19 21:27:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 19:27:16 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274297236.87.0.719292879068.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the Rietveld upload.  I haven't had a chance to review this properly yet, but hope to do so within the next few days.

One question: the production list you added to the docs says:

  format_string: (`byte_order_specifier`? `type_string`)*

This suggests that format strings like '<' and '<>b' are invalid;  is that correct, or should the production list be something like:

  format_string: (`byte_order_specifier` | `type_string`)*

?  Whether these cases are valid or not (personally, I think they should be), we should add some tests for them.  '<' *is* currently valid, I believe.


The possibility of mixing native size/alignment with standard size/alignment in a single format string makes me a bit uneasy, but I can't see any actual problems that might arise from it (equally, I can't imagine why anyone would want to do it).  I wondered briefly whether padding has clear semantics when a '@' appears in the middle of a format string, but I can't see why it wouldn't have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed May 19 21:38:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 19:38:56 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274297936.23.0.338219320215.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Travis, this issue is still assigned to you.  Do you plan to work on this at some stage, or may I unassign you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed May 19 21:46:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 19:46:21 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274298381.75.0.275688721039.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Something's not quite right: the _struct module fails to compile for me with this patch.  I get:

/Users/dickinsm/python/svn/py3k/Modules/_struct.c: In function ?s_unpack?:
/Users/dickinsm/python/svn/py3k/Modules/_struct.c:1730: error: ?PyStructObject? has no member named ?s_codes?
/Users/dickinsm/python/svn/py3k/Modules/_struct.c: In function ?s_unpack_from?:
/Users/dickinsm/python/svn/py3k/Modules/_struct.c:1765: error: ?PyStructObject? has no member named ?s_codes?

The offending lines both look like:

    assert(soself->s_codes != NULL);

presumably that should be:

    assert(soself->s_tree->s_codes != NULL);

After making that change, and successfully rebuilding, this assert triggers:

test_705836 (__main__.StructTest) ... Assertion failed: (soself->s_tree->s_codes != NULL), function s_unpack, file /Users/dickinsm/python/svn/py3k/Modules/_struct.c, line 1730.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed May 19 21:51:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 19:51:31 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274298691.07.0.398807036959.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, it should have been:

assert(soself->s_tree != NULL);

Got it now.  All tests pass. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed May 19 21:56:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 May 2010 19:56:17 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274298977.42.0.54871868095.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more design question.  For something like: '<HT{>H}H', what endianness should be used when packing/unpacking the last 'H'?  Should the switch to '>' within the embedded struct be regarded as local to the struct?

With your patch, I get:

>>> pack('<HT{>H}H', 1, (2,), 3)
b'\x01\x00\x00\x02\x00\x03'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed May 19 22:10:52 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 May 2010 20:10:52 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1274299852.01.0.148790333022.issue7902@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7902>
_______________________________________

From report at bugs.python.org  Wed May 19 22:11:47 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 May 2010 20:11:47 +0000
Subject: [issue8667] Link to PEP 3147 from importlib docs
In-Reply-To: <1273362693.55.0.571697250376.issue8667@psf.upfronthosting.co.za>
Message-ID: <1274299907.17.0.0552090613381.issue8667@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8667>
_______________________________________

From report at bugs.python.org  Wed May 19 22:31:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:31:34 +0000
Subject: [issue8589] test_warnings.CEnvironmentVariableTests.test_nonascii
	fails under an ascii terminal
In-Reply-To: <1272711919.88.0.504421520723.issue8589@psf.upfronthosting.co.za>
Message-ID: <1274301094.38.0.602307211212.issue8589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, Python 3.1 doesn't use the PYTHONWARNINGS variable: commit blocked in 3.1 (r81362).

----------
dependencies:  -regrtest: use backslashreplace error handler for stdout
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8589>
_______________________________________

From report at bugs.python.org  Wed May 19 22:32:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:32:58 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1274301178.87.0.695326965836.issue8663@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I commited to patch on distutils.log in r81359 (py3k)

Backported to 3.1 as r81363.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 22:33:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:33:37 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1274301217.68.0.0311441678481.issue8663@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 22:41:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:41:26 +0000
Subject: [issue8766] Segmentation fault with empty "encodings" subdirectory of
	directory in PYTHONPATH
In-Reply-To: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>
Message-ID: <1274301686.62.0.687603467251.issue8766@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fix commited to py3k (r81364). Wait for the buildbots beforing doing the backport.

----------
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8766>
_______________________________________

From report at bugs.python.org  Wed May 19 22:45:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:45:46 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1274301946.32.0.65140538478.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8611.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Wed May 19 22:45:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:45:54 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274301954.31.0.96307035691.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #4352.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Wed May 19 22:47:00 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 20:47:00 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1273340321.62.0.764550030132.issue8663@psf.upfronthosting.co.za>
Message-ID: <1274302020.51.0.586092398036.issue8663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I thought you had a unit test, I don't see any in your commit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 22:49:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 20:49:15 +0000
Subject: [issue8663] Failed compile in a non-ASCII path
In-Reply-To: <1274302020.51.0.586092398036.issue8663@psf.upfronthosting.co.za>
Message-ID: <201005192249.09073.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I thought you had a unit test, I don't see any in your commit

"patch -p0 < ... && svn ci" doesn't include new files. I forgot it.

r81361 includes the new file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8663>
_______________________________________

From report at bugs.python.org  Wed May 19 22:55:20 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 19 May 2010 20:55:20 +0000
Subject: [issue8769] Straightforward usage of email package fails to round-trip
In-Reply-To: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>
Message-ID: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

The attached test program shows how parsing an e-mail message with the email package, then converting the resulting message to a string, fails to round-trip properly.  Instead it breaks the encoding of the subject line.

The root of the problem: the subject is RFC-2047 quoted, long enough to require line wrapping, and it contains one of the splitchars used by Header.encode() -- meaning a semi-colon or comma.  In my example, this is:

Subject: =?utf-8?Q?2010_Foundation_Salary_and_Benefits_Report;_Important_Legislative_Efforts?=

Parsing the message turns that into a string S.  generator.Generator._write_headers() then outputs Header(S).encode(), so it keeps treating the value as an ASCII string, and therefore breaks the header at the semicolon, resulting in:
  
Subject: =?utf-8?Q?2010_Foundation_Salary_and_Benefits_Report;<NEWLINE><SPACE>_Important_Legislative_Efforts?=

Newline and space aren't legal in Q encoding, so MUAs give up and display all the =?utf-8?Q? stuff.

----------
assignee: barry
components: Library (Lib)
files: email-roundtrip-failure.py
keywords: patch
messages: 106100
nosy: akuchling, barry
priority: normal
severity: normal
status: open
title: Straightforward usage of email package fails to round-trip
versions: Python 2.7
Added file: http://bugs.python.org/file17410/email-roundtrip-failure.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Wed May 19 22:59:44 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 19 May 2010 20:59:44 +0000
Subject: [issue8769] Straightforward usage of email package fails to round-trip
In-Reply-To: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>
Message-ID: <1274302784.42.0.748156911127.issue8769@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The attached patch is a possible fix; it uses the decode_header() and make_header() functions to figure out the encoding properly; it fixes my example, at least.  But does it increase the odds of crashing on messages with malformed headers?  Should it go into 2.7 given that we're at the RC stage?  What about 2.6?

(BTW, Barry, I noticed this because messages being sent through Mailman were coming out with broken subject lines.  The system generating the messages is slightly weird -- doing the UTF-8 quoting is unnecessary since the subject contains no special characters -- but I think Mailman shouldn't be breaking subject lines.  I haven't verified that this Python fix actually fixes Mailman, but I think this is a Python bug, not a Mailman bug.)

----------
Added file: http://bugs.python.org/file17411/issue8769.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Wed May 19 23:00:29 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 19 May 2010 21:00:29 +0000
Subject: [issue8769] Straightforward usage of email package fails to round-trip
In-Reply-To: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>
Message-ID: <1274302829.39.0.601165268789.issue8769@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Minor fix to the patch: the import of Header could actually be removed, since the class is no longer referenced at all with this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Wed May 19 23:07:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 21:07:39 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274303259.55.0.672323624239.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If I understood correctly, this issue is a regression introduced by r67055 (to fix #4213). Read: http://bugs.python.org/issue4213#msg75387

See also r67057 (issue #3723).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Wed May 19 23:09:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 21:09:26 +0000
Subject: [issue1608805] Py_FileSystemDefaultEncoding can be non-canonical
Message-ID: <1274303366.22.0.665142167754.issue1608805@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of #4213 which was fixed by r67055 (py3k).

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1608805>
_______________________________________

From report at bugs.python.org  Wed May 19 23:16:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 21:16:00 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1274303760.13.0.235824700748.issue4388@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Wed May 19 23:33:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 21:33:34 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1274304814.89.0.810281427665.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is specific to Mac OS X because the file system encoding is hardcoded to UTF-8 on this OS. As written in msg76244, the problem is that the encoding is different for input (sys.argv) and output arguments (arguments of child processes). As written in msg76255, program arguments are encoded to the locale (terminal) encoding.

Finally, the problem is that subprocess, os.exec*(), etc. encode command line arguments with the file system encoding instead of the locale encoding.

On Linux, it just work because the file system encoding is the locale encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Wed May 19 23:50:45 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 19 May 2010 21:50:45 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274305845.05.0.253505201287.issue8759@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

@Ronald: Ah, I see. So on Mac, Python 2.7 (with default site configuration) will not pickup packages installed in ~/.local, correct? It will, from now onwards, only consider ~/Library/Package as the user site directory? I ask because I just want to double check before modifying PyPM (which has ~/.local hardcoded in the client) to support this change.

@Tarek: I have user site enabled; didn't change anything .. just the default settings:
$ /tmp/apy27/bin/python -m site
sys.path = [
    '/home/sridharr/as/apy/trunk',
    '/tmp/apy27/lib/python27.zip',
    '/tmp/apy27/lib/python2.7',
    '/tmp/apy27/lib/python2.7/plat-linux2',
    '/tmp/apy27/lib/python2.7/lib-tk',
    '/tmp/apy27/lib/python2.7/lib-old',
    '/tmp/apy27/lib/python2.7/lib-dynload',
    '/home/sridharr/.local/lib/python/2.7/site-packages',
    '/tmp/apy27/lib/python2.7/site-packages',
    '/tmp/apy27/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info',
]
USER_BASE: '/home/sridharr/.local' (exists)
USER_SITE: '/home/sridharr/.local/lib/python/2.7/site-packages' (exists)
ENABLE_USER_SITE: True

...

That is strange user site location - "python/2.7/site-packages" really? Shouldn't it be "python2.7/site-packages"?

----------
title: 2.7: wrong user site directory on Linux; totally missing on OSX -> 2.7: wrong user site directory on Linux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Wed May 19 23:55:23 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 19 May 2010 21:55:23 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274306123.97.0.809496961418.issue8729@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Will you post to Rietveld, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Wed May 19 23:58:18 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 19 May 2010 21:58:18 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274306298.22.0.580130849005.issue8759@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On further analysis:

$ /tmp/apy27/bin/python -c "from sysconfig import get_path; print get_path('purelib', 'posix_user')"
/home/sridharr/.local/lib/python/2.7/site-packages
$

>From sysconfig.py:

    'posix_user': {
        'stdlib': '{userbase}/lib/python/{py_version_short}',
        'platstdlib': '{userbase}/lib/python/{py_version_short}',
        'purelib': '{userbase}/lib/python/{py_version_short}/site-packages',
        'platlib': '{userbase}/lib/python/{py_version_short}/site-packages',

Ah, there is the bug!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Wed May 19 23:59:37 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 21:59:37 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274306377.62.0.252643474321.issue8759@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

"python/2.7/site-packages" is a typo in sysconfig, it should be "python2.7/site-packages" you are right.

Fixing it..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Thu May 20 00:28:19 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 22:28:19 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274308099.84.0.368584421594.issue8759@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in r81371, r81372

Thanks!

I let you close the issue once you are through with the rest of the talk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Thu May 20 00:43:18 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 19 May 2010 22:43:18 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

"python2.7 -m sysconfig" at the moment does not print anything. "python2.7 -m site", for instant, prints useful information.

Perhaps the output of `sysconfig.get_path` can be pretty printed?

----------
assignee: tarek
components: Distutils
messages: 106111
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: Make 'python -m sysconfig' print something useful
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Thu May 20 00:49:38 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 22:49:38 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274309378.15.0.203471547628.issue8770@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

You mean get_paths ?

It could also print out get_config_vars() output

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Thu May 20 00:49:57 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 22:49:57 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274309397.19.0.487097504921.issue8770@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Thu May 20 00:52:57 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 19 May 2010 22:52:57 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274309577.09.0.257358706635.issue8770@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Yes, get_paths(). It could also print get_config_vars(), yes. 

If you want to make it sophisticated you could support arguments/options using the 'argparse' module. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Thu May 20 00:59:49 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 19 May 2010 22:59:49 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274309989.44.0.693058731428.issue8770@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

weird, just realized "python -m site" doesn't print anything for me..

> If you want to make it sophisticated you could support arguments/options using the 'argparse' module. :)

Let's add the simplest case at first ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Thu May 20 01:05:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 May 2010 23:05:37 +0000
Subject: [issue8559] test_gdb: test_strings() fails with ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1274310337.45.0.891359257305.issue8559@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r81375 improves unicode support of libpython.py. I hope that it will be enough to fix test_strings() failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8559>
_______________________________________

From report at bugs.python.org  Thu May 20 01:15:11 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Wed, 19 May 2010 23:15:11 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1274310911.66.0.942926278414.issue3819@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

FYI, this change caused a regression in Mercurial - see http://mercurial.selenic.com/bts/issue2179.

----------
nosy: +kiilerix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3819>
_______________________________________

From report at bugs.python.org  Thu May 20 01:37:27 2010
From: report at bugs.python.org (Alice Bevan-McGregor)
Date: Wed, 19 May 2010 23:37:27 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>


New submission from Alice Bevan-McGregor <alice at gothcandy.com>:

Using the wsgiref simple HTTP server or any other capable of > 2000 requests/sec. demonstrates an issue with Macintosh sockets.

Mac OS X Version: 10.6.3 (Build 10D573)
Python Version: 2.6.1 (32-bit)

The minimal application needed to demonstrate the problem is:

    import sys, cStringIO
    from wsgiref.simple_server import make_server
    
    sys.stderr = cStringIO.StringIO() # disable request logging
    
    def app(environ, start_response):
        start_response("200 OK", [('Content-Type', 'text/plain')])
        return ['Hello world!\n']
    
    httpd = make_server('', 8080, app)
    httpd.serve_forever()

Then hammer the server using Apache Bench:

    ab -n 20000 -c 5 http://127.0.0.1:8080/

At almost exactly the 16000 request mark socket connections begin to time out.  Sockets are then freed up at the rate of about 40/second (on my box).  Killing the ab run when it freezes then immediately re-trying (and cancelling after a few seconds) will show this rate.  Time must pass for some connection 'pool' to free the connections before you can do another 16000 requests.

This problem does not appear on the following setup:

Operating System: Gentoo Linux
Python Version: 2.6.4 (32-bit)

----------
components: Library (Lib)
messages: 106117
nosy: amcgregor
priority: normal
severity: normal
status: open
title: Socket freezing under load issue on Mac.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Thu May 20 01:41:50 2010
From: report at bugs.python.org (Alice Bevan-McGregor)
Date: Wed, 19 May 2010 23:41:50 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1274312510.95.0.863861935045.issue8771@psf.upfronthosting.co.za>


Alice Bevan-McGregor <alice at gothcandy.com> added the comment:

I can confirm this issue also effecting 2.5.4 on my Mac.

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Thu May 20 01:59:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 May 2010 23:59:24 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1274313564.96.0.671295344186.issue8771@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why do you think this is a bug in Python?  I'm not yet saying it isn't, but we'll need additional information to show that it is.  Given that it works on Linux, it seems like the most likely case would be that it is an issue with the OS (perhaps requiring adjusting OS tuning parameters), since the Python socket library is a fairly thin wrapper around the OS socket library.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Thu May 20 02:03:31 2010
From: report at bugs.python.org (Alice Bevan-McGregor)
Date: Thu, 20 May 2010 00:03:31 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1274313811.0.0.390524035349.issue8771@psf.upfronthosting.co.za>


Alice Bevan-McGregor <alice at gothcandy.com> added the comment:

Unfortunately, unless I can get instructions on how to properly diagnose socket libraries, I've exhausted my ability to debug this.  I used to be a C programmer, but that was 12 years ago.

I'm hoping to a) confirm the problem exists on Mac (not just my computer), and b) get someone familiar with Python's socket implementation and socket programming in general to figure out what's actually going on here.

I also don't have access to Apple's radar bug tracker to check there.  :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Thu May 20 02:07:18 2010
From: report at bugs.python.org (Bernie H. Innocenti)
Date: Thu, 20 May 2010 00:07:18 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1274314038.23.0.698290210185.issue2504@psf.upfronthosting.co.za>


Bernie H. Innocenti <bernie at codewiz.org> added the comment:

While we're waiting for this patch to be upstreamed, what's the best way to emulate this functionality with the current gettext module?

I'm looking at the patch and it seems that code similar to this might work?

  def pgettext(ctx, msg):
     return gettext(ctx + "\x04" + msg)

----------
nosy: +bernie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu May 20 02:26:41 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 00:26:41 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1274315201.76.0.689868819949.issue444582@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Thu May 20 02:37:11 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 00:37:11 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Currently there is no way to get the default scheme for *current* platform other than plainly *assuming* that that is os.name unless it is posix, in which case it becomes posix_prefix. 

PyPM needs to know this. But I am slightly reluctant to hardcode it. I would rather use the _get_default_scheme() .. but only if it is known to be maintained for backward compat.

Thoughts?

----------
assignee: tarek
components: Distutils
messages: 106122
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: sysconfig: _get_default_scheme can be made public?
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 02:49:03 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 00:49:03 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274316543.49.0.459176748413.issue8772@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ideally I like to have a function like this:

            def get_current_scheme(usersite=False):
                scheme = os.name
                if usersite:
                    scheme += '_user'
                elif scheme == 'posix':
                    scheme = 'posix_prefix'

This would make it very easy to find the scheme for current Python installation - be it the global site-packages, or virtualenv or user site directory.

Though, generally it can take into consideration other "sub schemes" as well - prefix, home and user:


             def get_current_scheme(subscheme=oneof('default', 'home', 'user')):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 02:59:15 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 20 May 2010 00:59:15 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1274317155.25.0.835556755083.issue2281@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee: gregory.p.smith -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2281>
_______________________________________

From report at bugs.python.org  Thu May 20 03:59:18 2010
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 20 May 2010 01:59:18 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1274320758.14.0.941393076174.issue8714@psf.upfronthosting.co.za>


Henry Precheur <henry at precheur.org> added the comment:

The bug is also present with Python 3.1 on OpenBSD 4.7-current.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Thu May 20 04:09:01 2010
From: report at bugs.python.org (Henry Precheur)
Date: Thu, 20 May 2010 02:09:01 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1274321341.76.0.517837647332.issue8714@psf.upfronthosting.co.za>


Changes by Henry Precheur <henry at precheur.org>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Thu May 20 04:25:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 02:25:37 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1274322337.32.0.47797434693.issue1184112@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This has been fixed in 2.7 and 3.2.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1184112>
_______________________________________

From report at bugs.python.org  Thu May 20 04:33:00 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 20 May 2010 02:33:00 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274322780.19.0.215908644831.issue8770@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Add get_paths()'s output seems reasonable and simple enough, also we could make the output format prettier.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Thu May 20 04:35:13 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 02:35:13 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1274322913.1.0.399883003922.issue4769@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

This appears to still be an issue in py3k.  I've attached the command and output when running ``python3 -m base64`` with various options and inputs.  If there's consensus on a solution, I'd be happy to take a crack at making a patch.

----------
nosy: +meatballhat
Added file: http://bugs.python.org/file17412/b64-decode-str-bytes-typeerror.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Thu May 20 04:45:16 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 02:45:16 +0000
Subject: [issue8773] mailbox module is needlessly executable
In-Reply-To: <1274323516.06.0.854227668919.issue8773@psf.upfronthosting.co.za>
Message-ID: <1274323516.06.0.854227668919.issue8773@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

While running various modules with the ``-m`` flag to check for command-line behavior, I noticed that the mailbox module currently has svn:executable set.  The module contains no ``if __name__ == '__main__'`` magic and, as one would expect, nothing happens when invoking ``python3 -m mailbox``.  Because svn doesn't support an extended diff format that deals with file modes, I would just propose that somebody with commit rights do the following::

    svn propdel svn:executable Lib/mailbox.py

----------
components: Library (Lib)
messages: 106128
nosy: meatballhat
priority: normal
severity: normal
status: open
title: mailbox module is needlessly executable
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8773>
_______________________________________

From report at bugs.python.org  Thu May 20 05:17:32 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 03:17:32 +0000
Subject: [issue8774] 0xe7 in ``heapq.__about__`` causes badness
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>


New submission from Dan Buch <daniel.buch at gmail.com>:

I noticed while running ``python3 -m tabnanny -v Lib/*.py`` that the process died at heapq.py.  The 0x37 char in "Fran?ois Pinard" (in the ``__about__`` attr) was the culprit.  The attached patch replaces it with '\xe7'.  Changing the encoding cookie was not necessary to make it work, but seemed like a good idea at the time (I forget if it even matters... haven't worked much in py3k yet.)

----------
components: Library (Lib)
files: fran?ois-pinard-killed-my-tabnanny.patch
keywords: patch
messages: 106129
nosy: meatballhat
priority: normal
severity: normal
status: open
title: 0xe7 in ``heapq.__about__`` causes badness
versions: Python 3.2
Added file: http://bugs.python.org/file17413/fran?ois-pinard-killed-my-tabnanny.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 05:17:48 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 03:17:48 +0000
Subject: [issue8774] 0xe7 in ``heapq.__about__`` causes badness
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274325468.36.0.0020024381683.issue8774@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 05:49:09 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Thu, 20 May 2010 03:49:09 +0000
Subject: [issue8746] *chflags detection broken on FreeBSD 9-CURRENT
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1274327349.33.0.5711868082.issue8746@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

.

----------
Added file: http://bugs.python.org/file17414/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Thu May 20 06:47:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 20 May 2010 04:47:00 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274330820.82.0.218901909507.issue8729@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Done: http://codereview.appspot.com/1193044

This is my first time using Rietveld.  Let me know if I've done anything wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Thu May 20 06:47:22 2010
From: report at bugs.python.org (Wil Clouser)
Date: Thu, 20 May 2010 04:47:22 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1274330842.75.0.235082892121.issue2504@psf.upfronthosting.co.za>


Wil Clouser <clouserw at gmail.com> added the comment:

Yes.  You can see an in-production implementation at http://github.com/clouserw/tower/blob/master/tower/__init__.py#L51 (I'm overriding ugettext to support an optional context).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu May 20 06:58:38 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 20 May 2010 04:58:38 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274331518.34.0.725931882139.issue8759@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Shridar: that is correct a framework install will not look in ~/.local, but only in ~/Library/Python/2.7  (there is an install scheme in distutils that describes the exact layout).

Technically the name "Python" subdirectory is sysconfig.get_config_var("PYTHONFRAMEWORK"), to ensure that frameworks with different values for --with-framework-name will use different subdirectories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Thu May 20 09:59:46 2010
From: report at bugs.python.org (Sergey Kirillov)
Date: Thu, 20 May 2010 07:59:46 +0000
Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with
	whitespace
In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za>
Message-ID: <1274342386.44.0.0519200733938.issue3073@psf.upfronthosting.co.za>


Changes by Sergey Kirillov <serg at rainboo.com>:


----------
nosy: +rushman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3073>
_______________________________________

From report at bugs.python.org  Thu May 20 11:08:54 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 20 May 2010 09:08:54 +0000
Subject: [issue8774] 0xe7 in ``heapq.__about__`` causes badness
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274346534.56.0.254674868282.issue8774@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

This is the problem with module tabnanny, it always tries to read the py source file as a platform-dependent encoded text module, that is, open the file with builtin function "open()", and with no encoding parameters. It doesn't parse the encoding cookie at the beginning of the fource file! So if a python source file contains some character not encoded in that platform-dependent encoding, the tabnanny module will fail on checking that source file. Not only heapq.py, but also several other stander modules.

That platform-dependent encoding is judged as following orders:
1. os.device_encoding(fd)
2. locale.preferredencoding()
3. ascii.

I wonder why tabnanny works in this way. Is this the intended behaviour?  On my flatform, if I use tabnanny to check a source file which contains some chinese characters and encoded in 'gbk', the UnicodeDecodedError will raise.

If this is not the intended behaviour, I guess if we want to fix this problem, we have to change the way tabnanny read the source file. Just like the way python compiler works. First, open the file in "rb" module, then try to detect the encoding use tokenize.detect_encoding() method, then use the dected encoding to open the source file again in text module.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 11:16:42 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 20 May 2010 09:16:42 +0000
Subject: [issue8774] 0xe7 in ``heapq.__about__`` causes badness
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274347002.3.0.73897118224.issue8774@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

I add "tim_one" to nosy list since I found this name in Misc/maintainers:tabnanny. Sorry if I did something improper.

If this is really a problem, I'm glad to apply a patch for it.

Thanks!

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 11:45:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 20 May 2010 09:45:11 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274348711.46.0.877695631731.issue8772@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Its a good idea to have that API. 

Now for the subscheme, 


   def get_current_scheme(subscheme=oneof('default', 'home', 'user')):

This doesn't work because the installed Python has already chosen a scheme between default or home.

So I'd rather have two APIs answering to that:

- get_current_scheme() : what's the default scheme for this python installation ?
- get_current_user_scheme() :  what's the default user scheme for his python installation

Next, if you want to browse the various available schemes for the platform, we could change "get_scheme_names()" and add a new parameter, saying that we want only the scheme for the current OS:

  get_scheme_names(current_platform=False)



(removing 2.7 as a target -- it's too late)

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 13:04:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 20 May 2010 11:04:22 +0000
Subject: [issue8774] 0xe7 in ``heapq.__about__`` causes badness
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274353462.42.0.866597420669.issue8774@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

PEP?8, section ?encodings?, tells that stdlib source code in 3.x should always use ASCII or UTF-8, without encoding magic comment (since UTF-8 is the default now and ASCII is a subset of UTF-8); it explicitly mentions author names in comments or docstrings as the use case for UTF-8 bytes instead of escapes.

tl;dr: Don?t mangle people?s names, fix tabnanny.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 13:33:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 11:33:19 +0000
Subject: [issue8559] test_gdb: test_strings() fails with ASCII locale
In-Reply-To: <1272463139.31.0.880014845784.issue8559@psf.upfronthosting.co.za>
Message-ID: <1274355199.03.0.980130591436.issue8559@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r81375 improves unicode support of libpython.py. I hope that it will be
> enough to fix test_strings() failures.

Ok, buildbots seem happy: "alpha Debian 3.x" is green again.

Python 3.1 doesn't have libpython.py: commit blocked (r81376).

I forward ported some code from py3k to trunk to fix support of non-BMP unicode characters: r81377. Commit blocked in py3k (r81378) and 2.6 (r81379).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8559>
_______________________________________

From report at bugs.python.org  Thu May 20 14:09:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 12:09:25 +0000
Subject: [issue8775] Use locale encoding to decode sys.argv,
	not the file system encoding
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The file system is hardcoded to UTF-8 on Mac OS X, whereas the locale encoding... depends on the locale. See issue #4388 for the details.

I think that we should use the locale encoding to encode and decode command line arguments. We have to create a new encoding variable used for the command line arguments:
 * Py_CommandLineEncoding
 * sys.getcmdlineencoding()
 * (no sys.setcmdlineencoding() please!)
 * ...

This encoding only should be used on POSIX: Windows native type is unicode (wchar_t*). It should be used to decode sys.argv and to encode child processes arguments (subprocess, os.exec*(), etc.)).

On Linux, it should change anything because the file system encoding is the locale encoding. Said differently, Python3 does already use the locale encoding for the command arguments on Linux.

If you pass a filename on the command line and then open it: the filename is decoded with the locale encoding, and then encoded with the file system encoding. I fear that it will fail if both encodings are differents...

----------
messages: 106139
nosy: haypo
priority: normal
severity: normal
status: open
title: Use locale encoding to decode sys.argv, not the file system encoding
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Thu May 20 14:10:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 12:10:56 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In some situations, the encoding of the command line is incorrect or unknown. sys.argv is decoded with the file system encoding which can be wrong. Eg. see issue #4388 (ok, it's a bug, it should be fixed).

As os.environb, it would be useful to have bytes version of sys.argv to have able to decide the encoding used to decode each argument, or to manipulate bytes if we don't care about the encoding.

See also issue #8775 which propose to add a new encoding to decode sys.argv.

----------
components: Interpreter Core, Unicode
messages: 106140
nosy: haypo
priority: normal
severity: normal
status: open
title: Bytes version of sys.argv
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Thu May 20 14:29:35 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 May 2010 12:29:35 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1274358575.09.0.0825753656663.issue8776@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> sys.argv is decoded with the file system encoding

IIRC this is not exact. Py_Main signature is 
    Py_Main(int argc, wchar_t **argv)
then PyUnicode_FromWideChar is used, and there is no conversion (except from UCS4 to UCS2).
The wchar_t strings themselves are built with mbstowcs(), the file system encoding is not used.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Thu May 20 14:32:47 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 May 2010 12:32:47 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274358767.72.0.464557190329.issue8760@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There is a message::
   'import site' failed; use -v for traceback
what do you get when you run "./python -v"?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Thu May 20 14:39:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 12:39:45 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1274359185.11.0.074282195914.issue8776@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The wchar_t strings themselves are built with mbstowcs(), 
> the file system encoding is not used.

Oops sorry, you are right, and it's worse :-) sys.argv is decoded using the locale encoding, but subprocess & cie use the file system encoding for the reverse operation. => it doesn't work if both encodings are different (#4388, #8775).

The pseudo-code to create sys.argv on Unix is:

 # argv is a bytes list
 encoding = locale.getpreferredencoding()
 sys.argv = [arg.decode(encoding, 'surrogateescape') for arg in argv]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Thu May 20 14:40:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 12:40:52 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1274359252.7.0.269998768427.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created to related issues:
 - #8775: Use locale encoding to decode sys.argv, not the file system encoding
 - #8776: Bytes version of sys.argv

If #8775 is fixed, it should fix this issue too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu May 20 14:46:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 12:46:16 +0000
Subject: [issue1512] Removal of stale code in pyconfig.h
In-Reply-To: <1196259247.47.0.175425290011.issue1512@psf.upfronthosting.co.za>
Message-ID: <1274359576.51.0.0185124044898.issue1512@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think there is harm in removing this block; it would cause PY_LONG_LONG not to be defined anymore. Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1512>
_______________________________________

From report at bugs.python.org  Thu May 20 14:47:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 12:47:28 +0000
Subject: [issue1445781] install fails on hard link
Message-ID: <1274359648.68.0.701984927187.issue1445781@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1445781>
_______________________________________

From report at bugs.python.org  Thu May 20 14:56:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 12:56:34 +0000
Subject: [issue1884] msilib.SetProperty(msilib.PID_CODEPAGE,
	'1252') raises 0x65d = type mismatch
In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za>
Message-ID: <1274360194.3.0.600466601304.issue1884@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the bug in this report. As you found out, you need to set the codepage property before setting any of the string properties. This is a requirement imposed by Microsoft, and has nothing to do with Python.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1884>
_______________________________________

From report at bugs.python.org  Thu May 20 14:56:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 12:56:51 +0000
Subject: [issue1855] Codepage unset in msilib.init_database()
In-Reply-To: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za>
Message-ID: <1274360211.32.0.952847979277.issue1855@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

[The original link seems down; I found a similar description at http://msdn.microsoft.com/en-us/library/aa372049%28VS.85%29.aspx]

I think you are misinterpreting the documentation. It doesn't say that the codepage property is required (in fact, they explicitly list the required properties, namely Template, Revision Number, Page Count, Word Count). What they do say is that *if* you want to set the codepage property, *then* you must set it before any other string property. Since we are not setting the codepage property at all, this requirement is irrelevant.

Closing the report as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1855>
_______________________________________

From report at bugs.python.org  Thu May 20 14:57:33 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 May 2010 12:57:33 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1274360253.08.0.657388853522.issue4388@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What if os.system(), os.execvp() and friends used "wcstombs" (or locale.preferredencoding) to convert arguments from unicode to bytes? this would at least guarantee round-trip when spawning another python interpreter.

An interesting test is to compare the effects of os.unlink(filename) and os.system('rm "%s"' % filename), where filename is non-ascii. Does it work today?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu May 20 14:58:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 12:58:06 +0000
Subject: [issue1566260] Better order in file type descriptions
Message-ID: <1274360286.84.0.278651420836.issue1566260@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1566260>
_______________________________________

From report at bugs.python.org  Thu May 20 14:58:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 12:58:31 +0000
Subject: [issue1542] Ship 32 and 64bit libs with MSI installer
In-Reply-To: <1196621987.22.0.834586722022.issue1542@psf.upfronthosting.co.za>
Message-ID: <1274360311.59.0.859369402604.issue1542@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542>
_______________________________________

From report at bugs.python.org  Thu May 20 15:02:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 13:02:05 +0000
Subject: [issue8775] Use locale encoding to encode command line arguments
	(subprocess, os.exec*(), etc.)
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1274360525.11.0.883510556106.issue8775@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fix the title: sys.argv is already decoded using the locale encoding on Unix, the problem is that it uses a (possibly) different encoding to encode command line arguments: file system encoding.

----------
title: Use locale encoding to decode sys.argv, not the file system encoding -> Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Thu May 20 15:37:48 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 13:37:48 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274362668.17.0.301805407887.issue8774@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
title: 0xe7 in ``heapq.__about__`` causes badness -> tabnanny improperly handles non-ascii source files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 15:38:21 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 13:38:21 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274362701.86.0.824166060409.issue8774@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


Removed file: http://bugs.python.org/file17413/fran?ois-pinard-killed-my-tabnanny.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 15:38:35 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 20 May 2010 13:38:35 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274362715.89.0.700145710743.issue8774@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

removed patch because the fix should be made to tabnanny itself

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Thu May 20 15:46:43 2010
From: report at bugs.python.org (Alberto Trevino)
Date: Thu, 20 May 2010 13:46:43 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274103249.44.0.284620021799.issue8739@psf.upfronthosting.co.za>
Message-ID: <1274363203.34.0.29483337537.issue8739@psf.upfronthosting.co.za>


Alberto Trevino <alberto at byu.edu> added the comment:

I have attached a version 2 of the patch.  This patch includes everything in the first version, and adds the following:

 - Support for help arguments (HELP MAIL, for example)
 - Support for setting the maximum message size from the command line

This last feature adds the -s or --size option to the command line.  It allows the user to specify the maximum size for the message.  It is set to 0 for the default, meaning no limit.  This mimics the original behavior of module.  If you specify a size (like --size 32768), it will reject messages larger than the specified number of bytes (32KiB in this case).  If you don't specify the size, the response of EHLP won't list SIZE as one of the extensions.  But, if a size is specified, then it will show it on EHLP.

Hopefully these two changes will address some of the concerns that have been brought up.

----------
Added file: http://bugs.python.org/file17415/smtpd.py-0.2-rfc5321-enhancements-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Thu May 20 15:50:46 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 20 May 2010 13:50:46 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274363446.08.0.994725574155.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> is that correct, or should the production list be something like:

Yup, you are right.  I will change the grammar.

> Whether these cases are valid or not (personally, I think they should 
> be), we should add some tests for them.  '<' *is* currently valid, I 
> believe.

I agree, they should be valid.  I will add more test cases.

> The possibility of mixing native size/alignment with standard 
> size/alignment in a single format string makes me a bit uneasy

I agree.  It is hard for me to see how this might be used.  In any case,
the relevant part of the PEP that I was following is:

"Endian-specification ('!', '@','=','>','<', '^') is also allowed inside the string so that it can change if needed. The previously-specified endian string is in force until changed. The default endian is '@' which means native data-types and alignment. If un-aligned, native data-types are requested, then the endian specification is '^'."

However, I am not quite sure how to interpret the last sentence.

> Should the switch to '>' within the embedded struct be regarded as 
> local to the struct?

No, there is no notion of scope here.  A given specifier is active until the next one is found.

> Ah, it should have been:
> 
> assert(soself->s_tree != NULL);

D'oh!  I missed that when I merge over to py3k -- I started this work on trunk.  Thanks.

----------
Added file: http://bugs.python.org/file17416/struct-string.py3k.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 16:10:29 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 20 May 2010 14:10:29 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274364629.87.0.401242238544.issue8611@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

After looking in #4352 deep I figured out what true separation of filesystem default encoding and utf8 python namespace is really too complicated.
For example import call stack chain converts module name from utf-8 to  filesystem in import.c:find_module. After that converted name used by PyImport_ExecCodeModule* as utf-8 name while actually it has filesystem encoding. That problem cannot be solved by "five-line patch" and Martin von Loevis suggested me to stop potentially dangerous big import.c changes in python 3.1 beta. 
I like importlib way (with maybe C implementation as next step) in terms of "true way" reorganization of python import machinery, but unfortunatelly Cannon has no time for that. From my perspective only big refactoring can solve encoding issues (and we can use excellent io implementation to open utf-8 named files in Windows using native unicode functions). We need to split 'module names' from 'filesystem pathes' clean. 
Maybe pure python importing is not easy - not sure. But reorganizing of current 'import spaghetti' is required. importlib (and PEP 302) introduced a nice way to do that.
I like to be volunteer for this task and I feel enough knowledge to implement and test cover at least windows and linux (MacOs is not big problem also). But I need a mentor (Petrou, Cannon - you are welcome) to make it done, done clear and stable, done in resonable time period.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Thu May 20 16:11:02 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 20 May 2010 14:11:02 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274364662.32.0.623489697621.issue8611@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Thu May 20 16:17:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 14:17:44 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1274363446.08.0.994725574155.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274365059.3297.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The possibility of mixing native size/alignment with standard 
> > size/alignment in a single format string makes me a bit uneasy
> 
> I agree.  It is hard for me to see how this might be used.

Without having anything more constructive to add, I also agree with this
gut feeling. Perhaps not all of the PEP needs implementing; we can just
add what is genuinely useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 16:26:02 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 20 May 2010 14:26:02 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274365562.98.0.75610477177.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the review.  I incorporated the check re-orderings.

I am also writing more tests.  Which already exposed a subtly that I was not expecting:


Python 3.2a0 (py3k:81284M, May 20 2010, 09:08:20) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> n = 2 ** 53
[37447 refs]
>>> complex(n + 2) == n + 2
True
[37457 refs]
>>> complex(n + 1) == n + 1
False
[37459 refs]
>>> complex(n + 3) == n + 3
False
[37460 refs]
>>> complex(n + 4) == n + 4
True
[37461 refs]
>>> 

It seems as if 'complex(n + delta) == n + delta' when 'delta' is even.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Thu May 20 16:26:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 14:26:15 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274365575.97.0.300011969331.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the new patch.

> "... If un-aligned, native data-types are requested, then the
> endian specification is '^'."
>
> However, I am not quite sure how to interpret the last sentence.

Hmm.  Seems like the PEP authors are proposing a new byteorder/alignment/size specifier here:  '^' = native byte-order + native size + no alignment.  I missed this before.

>> Should the switch to '>' within the embedded struct be regarded as 
>> local to the struct?

>No, there is no notion of scope here.  A given specifier is active >until the next one is found.

Okay.  I wonder whether that's the most useful thing to do, though.

As a separate issue, I notice that the new 'T{}' code doesn't respect multiplicities, e.g., as in 'H3T{HHL}'.  Is that intentional/desirable?

>>> struct.pack('H3T{HHL}', 1, (2, 3, 4))
b'\x01\x00\x02\x00\x03\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00'

If we don't allow multiplicities, this should produce an exception, I think.  If we do allow multiplicities (and I don't immediately see why we shouldn't), then we're going to have to be clear about how endianness behaves in something like:

'>H3T{H<H}'

So the first inner struct here would be treated as '{>H<H}'.  Would the next two be identical to this, or would they be as though the whole thing were '>HT{H<H}T{H<H}T{H<H}', in which case the 2nd and 3rd substructs are both effectively '<H<H', while the first is '>H<H'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 16:36:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 14:36:59 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274366219.57.0.632871144031.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It seems as if 'complex(n + delta) == n + delta' when 'delta' is even.

For n = 2**53, and 0 <= delta <= 2**53, this sounds about right;  the reason is that the numbers in the range [2**53, 2**54] that are exactly representable as an IEEE 754 double are the even numbers.  Similarly, the only numbers in [2**54, 2**55] that are representable are multiples of 4, etc.

Thanks for the updated patch;  I'll take a closer look tonight, and apply it if all looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Thu May 20 17:22:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 15:22:34 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274368954.79.0.311802315653.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

As I wrote, I have an huge patch somewhere in my harddrive fixing this issue. But I don't want to publish it because it's really huge. I prefer to fix the problem step by step. I fixed most related issues: see the dependency list of #8242. I will publish the big patch shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Thu May 20 17:59:49 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 20 May 2010 15:59:49 +0000
Subject: [issue8771] Socket freezing under load issue on Mac.
In-Reply-To: <1274312247.36.0.878213869408.issue8771@psf.upfronthosting.co.za>
Message-ID: <1274371189.24.0.451800051533.issue8771@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Have you looked at the number of TIME_WAIT sockets you have on the system when your benchmark gets to the 16000 request mark?

This looks exactly like a regular TCP limitation to me.  You'll find the limit on any platform, not just OS X.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8771>
_______________________________________

From report at bugs.python.org  Thu May 20 18:07:54 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 16:07:54 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274348711.46.0.877695631731.issue8772@psf.upfronthosting.co.za>
Message-ID: <9C37FA28-40C3-4FCF-9670-90AECBECC5ED@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-05-20, at 2:45 AM, Tarek Ziad? wrote:

> So I'd rather have two APIs answering to that:
> 
> - get_current_scheme() : what's the default scheme for this python installation ?
> - get_current_user_scheme() :  what's the default user scheme for his python installation

+1

> Next, if you want to browse the various available schemes for the platform, we could change "get_scheme_names()" and add a new parameter, saying that we want only the scheme for the current OS:
> 
>  get_scheme_names(current_platform=False)

+1 as well. Perhaps `get_scheme_names(all=True)`? This seems like it can be done for 2.7, if found to be worthy of implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 18:15:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 16:15:44 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274372144.93.0.654767210007.issue8765@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The initial problem here is that we can't write unicode to a buffered 
> binary stream (TypeError), but we can do it with an unbufferred raw 
> stream - as the C implementation of the latter does string coercion 
> instead of raising TypeError.
> Shouldn't we unify the behaviour of binary streams in such cases ?

Yes, we certainly should. This is probably an oversight or a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Thu May 20 18:23:40 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 16:23:40 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274372620.46.0.481962075007.issue8772@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> removing 2.7 as a target -- it's too late

If contribute a patch to `get_current_scheme` and `get_current_user_scheme`, will be accepted as part of 2.7?

Roughly I would do something like this:

            scheme = os.name
            if usersite: # get_current_user_scheme
                if sys.platform == 'darwin':
                    scheme = 'osx_framework_user'
                else:
                    scheme += '_user'
            elif scheme == 'posix':
                scheme = 'posix_prefix'
            return scheme

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 18:24:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 16:24:49 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274372689.62.0.752845665832.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

After a bit more thought (and after soliciting a couple of opinions on #python-dev), I'm convinced that endianness changes within a substruct should be local to that substruct:

- it makes the meaning of '>2T{H<H}' both unsurprising and easy to understand:  i.e., it would be interpreted exactly as '>T{H<H}T{H<H}', and  both substructs would behave like '>H<H'.

- I suspect it's the behaviour that people expect

- it may make dynamic creation of struct format strings easier/less bug-prone.


But now I've got a new open issue:  how much padding should be inserted/expected (for pack/unpack respectively) between the 'B' and the 'T{...}' in a struct format string of the form 'BT{...}'?

For this, I don't think we can hope to exactly comply with the platform ABI in all cases.  But I think there's a simple rule that would work 99% of the time, and that does match the ABI on common platforms (though I'll check this), namely that the alignment requirement of the 'T{...}' struct should be the least common multiple of the alignment requirements of any of its elements.  (Which will usually translate to the largest of the alignment requirements, since those alignments are usually all going to be powers of 2.)

And *this* is where things get tricky if the alignment/byteorder/size specifier is changed midstream, since then it doesn't seem clear what alignments would contribute to the lcm above.  I'm tempted to suggest that for native mode, changing the specifier be disallowed entirely.

Travis, any comments on any of this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 18:26:44 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 16:26:44 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274372804.46.0.0739306119852.issue8772@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Here it is:

        def get_current_scheme():
            scheme = os.name
            if scheme == 'posix':
                scheme = 'posix_prefix'
            return scheme

        def get_current_user_scheme():
            scheme = os.name
            if sys.platform == 'darwin':
                scheme = 'osx_framework_user'
            else:
                scheme += '_user'
            return scheme

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 18:29:04 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 20 May 2010 16:29:04 +0000
Subject: [issue8775] Use locale encoding to encode command line arguments
	(subprocess, os.exec*(), etc.)
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1274372944.8.0.900989173522.issue8775@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Thu May 20 18:30:21 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 20 May 2010 16:30:21 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1274373021.13.0.071155631358.issue8776@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Thu May 20 18:35:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 16:35:14 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274373314.06.0.861746719012.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry, dropping this again.  I've got caught up with too many non-datetime related issues.

----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Thu May 20 19:07:42 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 20 May 2010 17:07:42 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The "barrier" synchronization primitive is often very useful.  It is simpler to use than an Event, for example, when waiting for threads to start up, or to finish.
The patch contains a simple barrier implementation based on a Condition variable, for your perusal.

See http://en.wikipedia.org/wiki/Barrier_(computer_science) for info.

This particular implementation contains an important feature:  The ability to adjust the 'count' of the barrier.  This is useful in case a thread dies for some reason, to avoid a deadlock for the other threads.

There is still no documentation, since this is only a proposal, but there is a unittest.

----------
components: Library (Lib)
files: barrier.patch
keywords: patch, patch
messages: 106167
nosy: krisvale
priority: normal
severity: normal
status: open
title: Add threading.Barrier
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17417/barrier.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu May 20 19:08:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 20 May 2010 17:08:33 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274375313.51.0.330256208483.issue8777@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu May 20 19:17:42 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 20 May 2010 17:17:42 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274375862.13.0.0848329190215.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> As a separate issue, I notice that the new 'T{}' code doesn't respect 
> multiplicities, e.g., as in 'H3T{HHL}'.  Is that 
> intentional/desirable?

That could have been an oversight on my part.  I don't see any immediate reason why we wouldn't allow it.

> But now I've got a new open issue:  how much padding should be 
> inserted/expected (for pack/unpack respectively) between the 'B' and 
> the 'T{...}' in a struct format string of the form 'BT{...}'?

Doesn't that depend on what is in the '...'?  For example, I would expect the same padding for 'BT{I}' and 'BI'.  In general, I would expect the padding to be the same for 'x+T{y+}' and 'x+y+'.  The 'T{...}'s are merely organizational, right?

> I'm tempted to suggest that for native mode, changing the specifier be 
> disallowed entirely.

I am tempted to suggest that we just go back to having one specifier at the beginning of the string :).  Things seem to be getting complicate without any clear benefits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 19:19:47 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 20 May 2010 17:19:47 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274375987.24.0.0380887091536.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Thanks for the updated patch;  I'll take a closer look tonight, and 
> apply it if all looks good.

I incorporated the changes locally and have not updated the patch yet.  I will update it later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Thu May 20 19:21:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 17:21:37 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274376097.02.0.175286320928.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

D'oh!  Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Thu May 20 19:23:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 17:23:05 +0000
Subject: [issue8775] Use locale encoding to decode sys.argv,
	not the file system encoding
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <4BF56FF6.60302@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I think that we should use the locale encoding to encode and decode command line arguments. 

I disagree. IIUC, this is only about OSX. Now, we shouldn't take any
action until either some OSX expert explains us how command line
arguments are being passed on OSX, or we find some Apple documentation
that can be taken as a specification.

I think the C locale is very poorly supported on OSX, and we shouldn't
really use it for anything. What may be useful is the terminal encoding
(which may be different both from UTF-8 and the locale encoding),
however, it's not possible to find out what the terminal encoding is.
In addition, programs may be started "directly" (i.e. not from the
terminal), in which case the terminal encoding would be irrelevant.

For file name arguments at least, it's very clear that the command line
arguments also use the file system encoding.

----------
nosy: +loewis
title: Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.) -> Use locale encoding to decode sys.argv, not the file system encoding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Thu May 20 19:24:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 May 2010 17:24:34 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <4BF5704E.2040206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> As os.environb, it would be useful to have bytes version of sys.argv
> to have able to decide the encoding used to decode each argument, or
> to manipulate bytes if we don't care about the encoding.

-1. Py_Main expects wchar_t*, so no byte-oriented representation of the
command line is readily available.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Thu May 20 19:30:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 17:30:37 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274376637.08.0.800725015034.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> For example, I would expect the same padding for 'BT{I}' and 'BI'.

Granted, yes.  But I wouldn't expect the same padding for 'BT{BI}' and 'BBI'.  'BT{BI}' should match a C struct which itself has an embedded struct.  For C, I get the following results on my machine:

#include <stdio.h>

/* corresponds to 'T{BI}' */
typedef struct {
  char y;
  int z;
} A;

/* corresponds to 'BT{BI}' */
typedef struct {
  char x;
  A yz;
} B;

/* corresponds to 'BBI' */
typedef struct {
  char x;
  char y;
  int z;
} C;

int main(void) {
  printf("sizeof(A) = %zu\n", sizeof(A));
  printf("sizeof(B) = %zu\n", sizeof(B));
  printf("sizeof(C) = %zu\n", sizeof(C));
  return 0;
}

/*                                                                               
Results on a (64-bit) OS X 10.6 machine:                                         
                                                                                 
sizeof(A) = 8                                                                    
sizeof(B) = 12                                                                   
sizeof(C) = 8                                                                    
*/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 19:33:38 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 20 May 2010 17:33:38 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274376818.82.0.0514888864421.issue8765@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, what's the expected behaviour then - implicitly converting unicode to bytes (like C RawFileIO), or raising a typeerror (like buffered streams do) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Thu May 20 19:33:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 17:33:58 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274376838.69.0.844902093251.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

(whoops -- used unsigned struct codes to correspond to signed C types there;  but it shouldn't make any difference to the sizes and padding).

> I am tempted to suggest that we just go back to having one specifier at the beginning of the string :).  Things seem to be getting complicate without any clear benefits.

Agreed.  Though if anyone following this issue wants to make the case that there are benefits to being able to change the endianness midway through a string, please do so!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 19:54:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 17:54:03 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274376818.82.0.0514888864421.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274378037.3297.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Allright, what's the expected behaviour then - implicitly converting
> unicode to bytes (like C RawFileIO), or raising a typeerror (like
> buffered streams do) ?

Sorry, I should have been clearer. The expected behaviour is to raise a
TypeError. The new io module was written for Python 3, where you
shouldn't mix bytes and unicode strings and expect things to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Thu May 20 20:13:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 May 2010 18:13:05 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274379185.73.0.113485755151.issue1289118@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Thu May 20 20:13:24 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 20 May 2010 18:13:24 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274379204.87.0.289526100439.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Granted, yes.  But I wouldn't expect the same padding for 'BT{BI}' and 
> 'BBI'.  'BT{BI}' should match a C struct which itself has an embedded 
> struct.  For C, I get the following results on my machine:

I wasn't sure.  The C99 standard does not specify what the behavior should be.  It is implementation defined.  I guess most implementations just set the alignment of the struct with the alignment of its most demanding member.

I need to change how the alignment for nested structures is computed.  Right now alignments are being computed as if the 'T{...}' codes were not there.  I will hold off until we decide what that rule should be, but I think the most demanding element rule seems reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 20:41:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 20 May 2010 18:41:48 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1274380908.34.0.642593829501.issue7902@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch, Meador. All I did was tweak the test slightly. Committed in:

+ 2.7: r81380
+ 2.6: r81381

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7902>
_______________________________________

From report at bugs.python.org  Thu May 20 20:50:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 18:50:05 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274381405.97.0.263467884633.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The C99 standard does not specify what the behavior should be.

Right;  it's down to the platform ABI.

I think the least common multiple of the alignment requirements of the struct members is the way to go, though.  It's difficult to imagine an ABI for which this lcm isn't the same thing as the largest struct member alignment, but I don't want to categorically say that such ABIs don't exist.

Here's a snippet from the gcc manual [1]:

"Note that the alignment of any given struct or union type is required by the ISO C standard to be at least a perfect multiple of the lowest common multiple of the alignments of all of the members of the struct or union in question."

I'm not sure I could identify the precise pieces of the standard that imply that requirement, though.

[1] http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Type-Attributes.html#Type-Attributes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 21:01:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 19:01:16 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274382076.29.0.855537835308.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Another snippet, from the latest public draft of the System V x86-64 ABI [1]:

"""Structures and unions assume the alignment of their most strictly aligned compo- nent. Each member is assigned to the lowest available offset with the appropriate alignment. The size of any object is always a multiple of the object?s alignment."""

I'd be fine with using the largest alignment, as above, instead of computing an lcm;  I can't believe it'll ever make a difference in practice.  For an empty struct (not allowed in C99, but allowed as a gcc extension, and allowed by the struct module), the alignment would be 1, of course.

[1] http://www.x86-64.org/documentation/abi.pdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 21:02:07 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 20 May 2010 19:02:07 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1274382127.8.0.860531446513.issue8772@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

No sorry, no API change for 2.7 at this point. We are in beta stage.

Now for the implementation, it's going to be a little more complex. We need to look at variables like PYTHONFRAMEWORK for instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Thu May 20 21:11:48 2010
From: report at bugs.python.org (Orlando Irrazabal)
Date: Thu, 20 May 2010 19:11:48 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274358767.72.0.464557190329.issue8760@psf.upfronthosting.co.za>
Message-ID: <4BF5893D.4000408@mendoza.gov.ar>


Orlando Irrazabal <oirraza at mendoza.gov.ar> added the comment:

Sorry, i didn't send that because the output is the same:

root at host:python-2.6.5# ./python -m test.regrtest -w -v
'import site' failed; use -v for traceback
Could not import runpy module

root at catastrix:python-2.6.5# ./python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
'import site' failed; traceback:
ImportError: No module named site
Python 2.6.5 (r265:79063, May 19 2010, 17:31:05) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
 >>>

If I run the command ../python -m test.regrtest -w -v from the Lib 
directory, I get the below output:

root at host:Lib# ../python -m test.regrtest -w -v
'import site' failed; use -v for traceback
Traceback (most recent call last):
   File "runpy.py", line 122, in _run_module_as_main
     "__main__", fname, loader, pkg_name)
   File "runpy.py", line 34, in _run_code
     exec code in run_globals
   File "/sw_install/python-2.6.5/Lib/test/regrtest.py", line 124, in 
<module>
     import cStringIO
ImportError: No module named cStringIO

Thanks

Orlando

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Thu May 20 21:27:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 19:27:52 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274383672.46.0.300811682428.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch giving more details in the doc, and explicitly mentioning the CVE entry.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file17418/setargvex2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Thu May 20 22:05:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 20:05:15 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274385915.69.0.503507884275.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would like to move forward on this. Does anyone have any comments or objections to the current proposal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Thu May 20 22:10:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 May 2010 20:10:16 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274386216.49.0.882273012064.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

dt.diff does not apply to current SVN version anymore.  I am attaching a quick update that does not change the actual calculation performed.  See issue1289118-py3k.diff.

I am still -1 for the reason I stated before, but I would like to review a working patch first before proposing a resolution.

----------
keywords: +patch
Added file: http://bugs.python.org/file17419/issue1289118-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Thu May 20 22:22:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 20 May 2010 20:22:49 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274386969.49.0.447514749193.issue1289118@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy:  -agthorr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Thu May 20 22:26:13 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:26:13 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1274387173.38.0.298126811519.issue1371826@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Thu May 20 22:26:40 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:26:40 +0000
Subject: [issue1109602] Need some setup.py sanity
Message-ID: <1274387200.03.0.912732874559.issue1109602@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109602>
_______________________________________

From report at bugs.python.org  Thu May 20 22:27:03 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:27:03 +0000
Subject: [issue967934] csv module cannot handle embedded \r
Message-ID: <1274387223.1.0.58381515684.issue967934@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue967934>
_______________________________________

From report at bugs.python.org  Thu May 20 22:27:19 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:27:19 +0000
Subject: [issue1072404] Bugs in _csv module - lineterminator
Message-ID: <1274387239.62.0.795008688898.issue1072404@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1072404>
_______________________________________

From report at bugs.python.org  Thu May 20 22:27:43 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:27:43 +0000
Subject: [issue5332] csv sniffer
In-Reply-To: <1235162733.25.0.482513842524.issue5332@psf.upfronthosting.co.za>
Message-ID: <1274387263.66.0.516482366482.issue5332@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5332>
_______________________________________

From report at bugs.python.org  Thu May 20 22:28:06 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:28:06 +0000
Subject: [issue1563079] code.InteractiveConsole() and closed sys.stdout
Message-ID: <1274387286.08.0.481516628961.issue1563079@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563079>
_______________________________________

From report at bugs.python.org  Thu May 20 22:28:24 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:28:24 +0000
Subject: [issue1690103] trace module borks __file__
Message-ID: <1274387304.1.0.230206403086.issue1690103@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1690103>
_______________________________________

From report at bugs.python.org  Thu May 20 22:28:41 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:28:41 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1274387321.98.0.76285406829.issue1675455@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Thu May 20 22:28:56 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:28:56 +0000
Subject: [issue1776160] Buffer overflow when listing deeply nested directory
Message-ID: <1274387336.24.0.201492795616.issue1776160@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1776160>
_______________________________________

From report at bugs.python.org  Thu May 20 22:29:09 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:29:09 +0000
Subject: [issue1054] scriptsinstall target fails in alternate build dir
In-Reply-To: <1188350602.15.0.357850795139.issue1054@psf.upfronthosting.co.za>
Message-ID: <1274387349.17.0.917663999193.issue1054@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054>
_______________________________________

From report at bugs.python.org  Thu May 20 22:29:23 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:29:23 +0000
Subject: [issue2403] Add figleaf coverage metrics
In-Reply-To: <1205869378.43.0.216108511876.issue2403@psf.upfronthosting.co.za>
Message-ID: <1274387363.42.0.660556572082.issue2403@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2403>
_______________________________________

From report at bugs.python.org  Thu May 20 22:29:35 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:29:35 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1274387375.88.0.347420666712.issue1467929@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Thu May 20 22:29:50 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:29:50 +0000
Subject: [issue1581906] test_sqlite fails on OS X if test_ctypes is run
Message-ID: <1274387390.06.0.099726124227.issue1581906@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581906>
_______________________________________

From report at bugs.python.org  Thu May 20 22:30:00 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:30:00 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1274387400.02.0.161172675471.issue4106@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Thu May 20 22:30:12 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:30:12 +0000
Subject: [issue998998] pickle bug - recursively memoizing class?
Message-ID: <1274387412.61.0.915301454893.issue998998@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue998998>
_______________________________________

From report at bugs.python.org  Thu May 20 22:30:30 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:30:30 +0000
Subject: [issue6251] c++ extension module implementation guide/example in
	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1274387430.09.0.775812621705.issue6251@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6251>
_______________________________________

From report at bugs.python.org  Thu May 20 22:30:41 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:30:41 +0000
Subject: [issue4506] 3.0 make test failures on Solaris 10
In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local>
Message-ID: <1274387441.88.0.506924275112.issue4506@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4506>
_______________________________________

From report at bugs.python.org  Thu May 20 22:30:52 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:30:52 +0000
Subject: [issue6520] urllib.urlopen does not have timeout parameter where as
	urllib2.urlopen has
In-Reply-To: <1247971941.19.0.568398315734.issue6520@psf.upfronthosting.co.za>
Message-ID: <1274387452.12.0.0435155086309.issue6520@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6520>
_______________________________________

From report at bugs.python.org  Thu May 20 22:31:03 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:31:03 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1274387463.84.0.0991155796101.issue5736@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Thu May 20 22:31:21 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:31:21 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1274387481.86.0.737267773058.issue6695@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Thu May 20 22:31:41 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:31:41 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1274387501.56.0.0233028435237.issue4010@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Thu May 20 22:31:56 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:31:56 +0000
Subject: [issue5148] gzip.open breaks with  'U' flag
In-Reply-To: <1233709542.39.0.638969424034.issue5148@psf.upfronthosting.co.za>
Message-ID: <1274387516.1.0.51961040742.issue5148@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5148>
_______________________________________

From report at bugs.python.org  Thu May 20 22:32:08 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:32:08 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1274387528.76.0.45412205448.issue6105@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Thu May 20 22:32:22 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:32:22 +0000
Subject: [issue7185] csv reader utf-8 BOM error
In-Reply-To: <1256208366.7.0.205796618954.issue7185@psf.upfronthosting.co.za>
Message-ID: <1274387542.45.0.19567655338.issue7185@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7185>
_______________________________________

From report at bugs.python.org  Thu May 20 22:32:35 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:32:35 +0000
Subject: [issue6186] test_thread occasionally reports unhandled exceptions on
	OS X
In-Reply-To: <1244016184.43.0.482761629197.issue6186@psf.upfronthosting.co.za>
Message-ID: <1274387555.88.0.930995360409.issue6186@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6186>
_______________________________________

From report at bugs.python.org  Thu May 20 22:32:48 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:32:48 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1274387568.12.0.364942471909.issue7247@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7247>
_______________________________________

From report at bugs.python.org  Thu May 20 22:33:01 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:33:01 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1274387581.59.0.00449302981109.issue7475@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu May 20 22:33:21 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:33:21 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1274387601.79.0.205980312308.issue766910@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
_______________________________________

From report at bugs.python.org  Thu May 20 22:33:35 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:33:35 +0000
Subject: [issue1374063] Broader iterable support for xmlrpclib
Message-ID: <1274387615.05.0.204134704965.issue1374063@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1374063>
_______________________________________

From report at bugs.python.org  Thu May 20 22:33:44 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:33:44 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1274387624.27.0.199260034678.issue2623@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2623>
_______________________________________

From report at bugs.python.org  Thu May 20 22:33:57 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:33:57 +0000
Subject: [issue3539] Problem with pgen make dependencies in certain
	circumstances
In-Reply-To: <1218416155.29.0.722740811463.issue3539@psf.upfronthosting.co.za>
Message-ID: <1274387637.08.0.527127025457.issue3539@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3539>
_______________________________________

From report at bugs.python.org  Thu May 20 22:34:05 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:34:05 +0000
Subject: [issue4086] support %z format in time.strftime and _strptime?
In-Reply-To: <1223551646.15.0.164355592546.issue4086@psf.upfronthosting.co.za>
Message-ID: <1274387645.99.0.0974914556417.issue4086@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4086>
_______________________________________

From report at bugs.python.org  Thu May 20 22:34:16 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:34:16 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1274387656.94.0.314775443439.issue3173@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Thu May 20 22:34:29 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:34:29 +0000
Subject: [issue4810] timeit needs "official" '--' flag
In-Reply-To: <18782.17333.839740.4416@montanaro-dyndns-org.local>
Message-ID: <1274387669.22.0.752550143837.issue4810@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4810>
_______________________________________

From report at bugs.python.org  Thu May 20 22:34:45 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:34:45 +0000
Subject: [issue2262] Helping the compiler avoid memory references in
	PyEval_EvalFrameEx
In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
Message-ID: <1274387685.71.0.644498180513.issue2262@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2262>
_______________________________________

From report at bugs.python.org  Thu May 20 22:34:58 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:34:58 +0000
Subject: [issue4888] misplaced (or misleading) assert in ceval.c
In-Reply-To: <1231476734.82.0.767072982695.issue4888@psf.upfronthosting.co.za>
Message-ID: <1274387698.5.0.817867453771.issue4888@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4888>
_______________________________________

From report at bugs.python.org  Thu May 20 22:35:11 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:35:11 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1274387711.96.0.0412446536377.issue4896@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Thu May 20 22:35:23 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:35:23 +0000
Subject: [issue7353] cporting docs recommend using Include/intobject.h,
	which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1274387723.3.0.757863077748.issue7353@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7353>
_______________________________________

From report at bugs.python.org  Thu May 20 22:35:34 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:35:34 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1274387734.74.0.861916310499.issue5683@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5683>
_______________________________________

From report at bugs.python.org  Thu May 20 22:35:45 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:35:45 +0000
Subject: [issue7686] redundant open modes 'rbb', 'wbb',
	'abb' no longer work on Windows
In-Reply-To: <1263342536.73.0.0502696558207.issue7686@psf.upfronthosting.co.za>
Message-ID: <1274387745.61.0.20622388741.issue7686@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7686>
_______________________________________

From report at bugs.python.org  Thu May 20 22:36:08 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:36:08 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1274387768.76.0.697409708897.issue1927@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1927>
_______________________________________

From report at bugs.python.org  Thu May 20 22:36:09 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 May 2010 20:36:09 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274387769.26.0.887039246152.issue8759@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Thanks.

> there is an install scheme in distutils that describes the exact layout

I figured that this is now exposed via the `sysconfig` module. There is also an old install scheme in `distutils.command.install`, but it seems to be outdated and is only applicable for 2.6.

My understanding is that, installers such as PyPM should use the scheme in distutils.command.install on 2.6 and the new sysconfig scheme for 2.7+.

Please feel free to close this issue (I can do it, but do not have the privileges to set the resolution field.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Thu May 20 22:36:27 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:36:27 +0000
Subject: [issue4753] Faster opcode dispatch on gcc
In-Reply-To: <1230325778.98.0.752974375077.issue4753@psf.upfronthosting.co.za>
Message-ID: <1274387787.63.0.261415234308.issue4753@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4753>
_______________________________________

From report at bugs.python.org  Thu May 20 22:36:46 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:36:46 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1274387806.51.0.331652238149.issue1777412@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Thu May 20 22:36:59 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:36:59 +0000
Subject: [issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun
	compiler)
Message-ID: <1274387819.87.0.892294357188.issue1544339@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544339>
_______________________________________

From report at bugs.python.org  Thu May 20 22:37:11 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:37:11 +0000
Subject: [issue1659] Tests needing network flag?
In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org>
Message-ID: <1274387831.34.0.70731832743.issue1659@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1659>
_______________________________________

From report at bugs.python.org  Thu May 20 22:37:23 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:37:23 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1274387843.58.0.377600563734.issue8406@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu May 20 22:37:26 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 20 May 2010 20:37:26 +0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1274387846.19.0.00855882035912.issue2054@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
_______________________________________

From report at bugs.python.org  Thu May 20 22:37:46 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:37:46 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1274387866.02.0.721436573907.issue4111@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
assignee: skip.montanaro -> 
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu May 20 22:37:58 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:37:58 +0000
Subject: [issue5671] Speed up pickling of lists in cPickle
In-Reply-To: <1238700497.01.0.638889592432.issue5671@psf.upfronthosting.co.za>
Message-ID: <1274387878.77.0.882166795997.issue5671@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5671>
_______________________________________

From report at bugs.python.org  Thu May 20 22:38:12 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:38:12 +0000
Subject: [issue1083] Confusing error message when dividing timedelta using /
In-Reply-To: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
Message-ID: <1274387892.09.0.293312382704.issue1083@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
_______________________________________

From report at bugs.python.org  Thu May 20 22:38:33 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:38:33 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1274387913.86.0.38364217313.issue4194@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Thu May 20 22:38:50 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:38:50 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1274387930.09.0.229249055184.issue1818@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1818>
_______________________________________

From report at bugs.python.org  Thu May 20 22:39:03 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:39:03 +0000
Subject: [issue4835] SIZEOF_SOCKET_T not defined
In-Reply-To: <18784.64475.338807.986695@montanaro.dyndns.org>
Message-ID: <1274387943.31.0.107369717636.issue4835@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4835>
_______________________________________

From report at bugs.python.org  Thu May 20 22:39:17 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:39:17 +0000
Subject: [issue1644818] Allow built-in packages and submodules as well as
	top-level modules
Message-ID: <1274387957.15.0.637249012748.issue1644818@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1644818>
_______________________________________

From report at bugs.python.org  Thu May 20 22:39:30 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:39:30 +0000
Subject: [issue504152] rfc822 long header continuation broken
Message-ID: <1274387970.39.0.885979652696.issue504152@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue504152>
_______________________________________

From report at bugs.python.org  Thu May 20 22:39:51 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:39:51 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1274387991.43.0.529440546961.issue1759169@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Thu May 20 22:40:12 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:40:12 +0000
Subject: [issue8392] unit tests rather light on testing __import__(..., level)
In-Reply-To: <1271203412.15.0.504789215632.issue8392@psf.upfronthosting.co.za>
Message-ID: <1274388012.18.0.249588217803.issue8392@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8392>
_______________________________________

From report at bugs.python.org  Thu May 20 22:40:39 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:40:39 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1274388039.6.0.58754740745.issue2736@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Thu May 20 22:41:00 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:41:00 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274388060.66.0.263722496759.issue6715@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu May 20 22:41:14 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:41:14 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1274388074.4.0.824520502372.issue4007@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Thu May 20 22:41:36 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:41:36 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274388096.34.0.563107051877.issue1289118@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Thu May 20 22:42:02 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:42:02 +0000
Subject: [issue1374063] Broader iterable support for xmlrpclib
Message-ID: <1274388122.9.0.739756450635.issue1374063@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
assignee: skip.montanaro -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1374063>
_______________________________________

From report at bugs.python.org  Thu May 20 22:42:14 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:42:14 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1274388134.24.0.69517768248.issue2623@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
assignee: skip.montanaro -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2623>
_______________________________________

From report at bugs.python.org  Thu May 20 22:42:26 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 20 May 2010 20:42:26 +0000
Subject: [issue1659] Tests needing network flag?
In-Reply-To: <18281.12938.264352.782990@montanaro.dyndns.org>
Message-ID: <1274388146.5.0.623683108204.issue1659@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
assignee: skip.montanaro -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1659>
_______________________________________

From report at bugs.python.org  Thu May 20 22:49:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 May 2010 20:49:09 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1274388549.89.0.867463243856.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more reference:

http://msdn.microsoft.com/en-us/library/9dbwhz68(v=VS.80).aspx

gives essentially the same rules for MSVC. "The alignment of the beginning of a structure or a union is the maximum alignment of any individual member. Each member within the structure or union must be placed at its proper alignment as defined in the previous table, which may require implicit internal padding, depending on the previous member."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Thu May 20 22:55:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 May 2010 20:55:28 +0000
Subject: [issue967934] csv module cannot handle embedded \r
Message-ID: <1274388928.31.0.590038614217.issue967934@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

At some point I added test_roundtrip_quoteed_newlines to the csv unit tests, and it passes both on trunk and py3k.  I believe if there was a bug here it has been fixed.  I just backported the test to 2.6 in r81382, and it passes there as well.  Closing as out of date.

Heh, I just noticed that the method name is misspelled :(

----------
nosy: +r.david.murray
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue967934>
_______________________________________

From report at bugs.python.org  Thu May 20 23:01:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 21:01:52 +0000
Subject: [issue8766] Segmentation fault with empty "encodings" subdirectory of
	directory in PYTHONPATH
In-Reply-To: <1274275642.68.0.971287952925.issue8766@psf.upfronthosting.co.za>
Message-ID: <1274389312.1.0.230079699414.issue8766@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Fix commited to py3k (r81364).

Ok, buildbots are happy: backported as r81383 in 3.1

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8766>
_______________________________________

From report at bugs.python.org  Thu May 20 23:09:06 2010
From: report at bugs.python.org (Goplat)
Date: Thu, 20 May 2010 21:09:06 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1274389746.18.0.806118669053.issue8745@psf.upfronthosting.co.za>


Goplat <mrnobo1024 at yahoo.com> added the comment:

Zipping up the Lib directory from the python source (1735 files) as a test, it took on average 0.10 sec to read the zip before, 0.04 sec after.

(To test the time taken by zipimport isolated from other startup costs, instead of actually getting the zip in the import path, I just ran

import time, zipimport; start = time.clock(); 
zipimport.zipimporter("lib.zip"); print time.clock() - start)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Thu May 20 23:42:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 May 2010 21:42:08 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274391728.74.0.127471207673.issue8760@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

no, the input is not the same, there is "ImportError: No module named site". I have tree more questions:

- Do you have a file named: /sw_install/python-2.6.5/Lib/site.py
- what it the output when you type "import sys; print sys.path"
- is there a file named "cStringIO.so" somewhere in the build tree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Thu May 20 23:44:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 21:44:10 +0000
Subject: [issue8766] Segmentation fault with empty "encodings" subdirectory of
	directory in PYTHONPATH
In-Reply-To: <1274389312.1.0.230079699414.issue8766@psf.upfronthosting.co.za>
Message-ID: <201005202344.03564.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Ok, buildbots are happy: backported as r81383 in 3.1

My test doesn't work on Windows. We cannot delete a directory if it's the 
current working directory: let's try r81384.

py3k commit is simpler because it uses support.test_cwd() ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8766>
_______________________________________

From report at bugs.python.org  Thu May 20 23:51:42 2010
From: report at bugs.python.org (Terrence Cole)
Date: Thu, 20 May 2010 21:51:42 +0000
Subject: [issue8778] typo in docs for symtable.SymbolTable.has_import_star
In-Reply-To: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>
Message-ID: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

The documentation for symtable.SymbolTable [http://docs.python.org/py3k/library/symtable.html] lists the function has_import_start.  This should be has_import_star, as listed in help(symtable.SymbolTable).

I've attached a patch, although it would probably be faster for a committer to just remove the 't' themselves.

----------
assignee: docs at python
components: Documentation
files: fix-has-import-star-doc.diff
keywords: patch
messages: 106194
nosy: docs at python, terrence
priority: normal
severity: normal
status: open
title: typo in docs for symtable.SymbolTable.has_import_star
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17420/fix-has-import-star-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8778>
_______________________________________

From report at bugs.python.org  Fri May 21 00:02:01 2010
From: report at bugs.python.org (Roman Gershman)
Date: Thu, 20 May 2010 22:02:01 +0000
Subject: [issue8779] utf8 codec fails to parse a character
In-Reply-To: <1274392921.12.0.376049496737.issue8779@psf.upfronthosting.co.za>
Message-ID: <1274392921.12.0.376049496737.issue8779@psf.upfronthosting.co.za>


New submission from Roman Gershman <romange at gmail.com>:

The following code fails to parse the attached file:


#!/usr/bin/python3.1

if __name__ == '__main__':
 f = open("c:\\1.txt", mode ='r', encoding='utf-8')
 for line in f:
     print (line)

----------
components: Unicode
files: 1.txt
messages: 106195
nosy: Roman.Gershman
priority: normal
severity: normal
status: open
title: utf8 codec fails to parse a character
versions: Python 3.1
Added file: http://bugs.python.org/file17421/1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8779>
_______________________________________

From report at bugs.python.org  Fri May 21 00:06:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 22:06:47 +0000
Subject: [issue8779] utf8 codec fails to parse a character
In-Reply-To: <1274392921.12.0.376049496737.issue8779@psf.upfronthosting.co.za>
Message-ID: <1274393207.87.0.794454767573.issue8779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

$ hexdump  -C 1.txt 
00000000  ec 0d 0a                                          |...|
00000003

This file is *not* encoded to utf8.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8779>
_______________________________________

From report at bugs.python.org  Fri May 21 00:10:52 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 20 May 2010 22:10:52 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274393452.64.0.657267555565.issue4870@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I like the approach of providing this feature as a single attribute instead of two separate methods (set/get_options()).
For what it's worth, I took a look at the patch without actually trying it, and it looks good overall, both tests and documentation which is particularly clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Fri May 21 00:14:37 2010
From: report at bugs.python.org (Orlando Irrazabal)
Date: Thu, 20 May 2010 22:14:37 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274391728.74.0.127471207673.issue8760@psf.upfronthosting.co.za>
Message-ID: <4BF5B42E.4000306@mendoza.gov.ar>


Orlando Irrazabal <oirraza at mendoza.gov.ar> added the comment:

I answer your questions

- yes, i have a file named /sw_install/python-2.6.5/Lib/site.py
- the output for the commands "import sys; print sys.path" is:
     ['', '/sw_install/python-2.6.5/lib/python26.zip', 
'/sw_install/python-2.6.5/lib/python2.6/', 
'/sw_install/python-2.6.5/lib/python2.6/plat-aix5', 
'/sw_install/python-2.6.5/lib/python2.6/lib-tk', 
'/sw_install/python-2.6.5/lib/python2.6/lib-old', 
'/sw_install/python-2.6.5/lib/python2.6/lib-dynload']
   , but my lib directory is named "Lib" not "lib".
   This problem may be because i haven't installed it yet?
- yes, the file "cStringsIO.so" exists in the directory 
/sw_install/python-2.6.5/build/lib.aix-5.3-2.6

thanks

/sw_install/python-2.6.5/Lib/site.py

El 20/05/2010 18:42, Amaury Forgeot d'Arc escribi?:
> Amaury Forgeot d'Arc<amauryfa at gmail.com>  added the comment:
>
> no, the input is not the same, there is "ImportError: No module named site". I have tree more questions:
>
> - Do you have a file named: /sw_install/python-2.6.5/Lib/site.py
> - what it the output when you type "import sys; print sys.path"
> - is there a file named "cStringIO.so" somewhere in the build tree?
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8760>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Fri May 21 00:17:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 22:17:07 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1274393827.43.0.794781027057.issue7384@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested issue7384-5-py3k.patch	on FreeBSD 8.0: it fixes the crash.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

From report at bugs.python.org  Fri May 21 00:20:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 22:20:24 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274394024.83.0.0201057929937.issue8760@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Fri May 21 00:24:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 22:24:02 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274394242.09.0.698120046689.issue1436346@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky, mark.dickinson
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri May 21 00:24:04 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 22:24:04 +0000
Subject: [issue8778] typo in docs for symtable.SymbolTable.has_import_star
In-Reply-To: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>
Message-ID: <1274394244.55.0.243007806647.issue8778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks. Fixed in r81385.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8778>
_______________________________________

From report at bugs.python.org  Fri May 21 00:29:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 22:29:10 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274394550.05.0.358047241095.issue8774@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The correct fix is to use tokenize.detect_encoding, if anyone wants to provide a patch.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Fri May 21 00:33:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 22:33:20 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274394800.04.0.844742626047.issue8774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The correct fix is to use tokenize.detect_encoding, 
> if anyone wants to provide a patch.

done :-) Attached patch opens the file in binary mode to call 
tokenize.detect_encoding() and then use the encoding to open the file a second time (in text (unicode) mode).

----------
nosy: +haypo
Added file: http://bugs.python.org/file17422/tabnanny_detect_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Fri May 21 00:42:13 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 22:42:13 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274395333.92.0.0386256954998.issue8774@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You should handle the case of encoding being None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Fri May 21 00:42:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 May 2010 22:42:41 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274395361.92.0.55379055219.issue1436346@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri May 21 00:48:56 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 22:48:56 +0000
Subject: [issue8779] utf8 codec fails to parse a character
In-Reply-To: <1274392921.12.0.376049496737.issue8779@psf.upfronthosting.co.za>
Message-ID: <1274395736.0.0.628951453639.issue8779@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8779>
_______________________________________

From report at bugs.python.org  Fri May 21 01:02:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 May 2010 23:02:33 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274396553.27.0.980796992809.issue8774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You should handle the case of encoding being None.

detect_encoding() never returns None for the encoding. If there is no cookie, utf8 is returned by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Fri May 21 01:12:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 23:12:54 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274396553.27.0.980796992809.issue8774@psf.upfronthosting.co.za>
Message-ID: <AANLkTikgk2zdiHOZVgQPBQnoyOxXcbJZqpiAjDy2BABz@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/5/20 STINNER Victor <report at bugs.python.org>:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> You should handle the case of encoding being None.
>
> detect_encoding() never returns None for the encoding. If there is no cookie, utf8 is returned by default.

Ah, right. looks ok then

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Fri May 21 01:17:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 May 2010 23:17:47 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274397467.31.0.643844939306.issue1436346@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I think this should be rejected.  The OP's premise was that t.timetuple()[7] was unreadable, but in the modern python, the same can be written as t.timetuple().tm_yday.  The later is only slightly less readable than the proposed t.yday().

For the other half of the proposal, Marc-Andre's mxDate code translates into only slightly more complicated stdlib datetime code:

def date_fromyday(year, yday):
   return date(year, 1, 1) + timedelta(yday - 1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri May 21 01:27:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 May 2010 23:27:17 +0000
Subject: [issue1436346] yday in datetime module
In-Reply-To: <1274397467.31.0.643844939306.issue1436346@psf.upfronthosting.co.za>
Message-ID: <1274398033.3141.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think this should be rejected.  The OP's premise was that
> t.timetuple()[7] was unreadable, but in the modern python, the same
> can be written as t.timetuple().tm_yday.

Could I suggest such example be added to the documentation, though?
The datetime / time jungle is difficult to navigate through, and I think
for most people it is not obvious that the answer to their needs is to
look at one of the attributes of the timetuple() result...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri May 21 02:01:23 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 21 May 2010 00:01:23 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1274400083.25.0.979058984151.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Ping...

We already missed the 2.7 boat. Any hope for 3.2?

----------
assignee:  -> prescod
keywords: +needs review -patch
nosy: +prescod, skip.montanaro -Garen
priority: normal -> 
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri May 21 02:59:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 May 2010 00:59:17 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1274403557.27.0.604062531722.issue8720@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Holger, what do you think of this alternate patch that instead makes getsourcefile smarter?  It's a simpler patch and doesn't change the API, and your tests (suitably modified) pass.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file17423/getsourcfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Fri May 21 03:33:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 May 2010 01:33:25 +0000
Subject: [issue1072404] Bugs in _csv module - lineterminator
Message-ID: <1274405605.15.0.742032497828.issue1072404@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The doc has been fixed; using lineterminator in reader has not been and is not likely to be implemented (unless someone wants to come forward with a patch). Processing files that use \r line endings does work; as indicated you use universal newline mode for the input file.  In Py3k you can wrap a BytesIO object in a TextIOWrapper to get universal newline parsing.

So, I'm closing this as wont fix, as suggested.  If someone does want to implement lineterminator for reader, they can open a new feature request issue.

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1072404>
_______________________________________

From report at bugs.python.org  Fri May 21 03:33:52 2010
From: report at bugs.python.org (Meador Inge)
Date: Fri, 21 May 2010 01:33:52 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274405632.47.0.75771239816.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

No problem!  I have attached the updated patch.

I am starting on the 2.7 patch now.

----------
Added file: http://bugs.python.org/file17424/issue-8748.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Fri May 21 03:40:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 May 2010 01:40:44 +0000
Subject: [issue5332] csv sniffer
In-Reply-To: <1235162733.25.0.482513842524.issue5332@psf.upfronthosting.co.za>
Message-ID: <1274406044.26.0.0648343516314.issue5332@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is in fact a doc bug.  The correct way to read a csv file in python3 is to open it in text mode with newline=''.  The docs have been updated to reflect this.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5332>
_______________________________________

From report at bugs.python.org  Fri May 21 03:41:37 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 May 2010 01:41:37 +0000
Subject: [issue2090] __import__ with fromlist=
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1274406097.16.0.650549249938.issue2090@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file16936/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
_______________________________________

From report at bugs.python.org  Fri May 21 03:58:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 May 2010 01:58:20 +0000
Subject: [issue8759] 2.7: wrong user site directory on Linux
In-Reply-To: <1274219864.93.0.0086254840372.issue8759@psf.upfronthosting.co.za>
Message-ID: <1274407100.4.0.406817240599.issue8759@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8759>
_______________________________________

From report at bugs.python.org  Fri May 21 04:21:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 May 2010 02:21:50 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1274408510.5.0.172441231479.issue4111@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: prescod -> 
keywords: +patch
nosy: +Garen -prescod, skip.montanaro
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri May 21 06:26:41 2010
From: report at bugs.python.org (Meador Inge)
Date: Fri, 21 May 2010 04:26:41 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274416001.27.0.462373579698.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

2.7 patch attached.  The implementation is mostly the same as the 3.2 one, but there is one quirk.  Namely, 2.7 (and other 2.x's) has the following odd behavior:

   >>> 1j < None
   False
   >>> 1j < 1
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: no ordering relation is defined for complex numbers

To perserve this behavior I had to do the type checks for 'int', 'long', 'complex', and 'float' at the beginning.  I tried 'PyNumber_Check' first, but it returns 1 for old-style classes since the number protocol is filled in for the 'instance' type.

----------
Added file: http://bugs.python.org/file17425/issue-8748.py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Fri May 21 09:32:48 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Fri, 21 May 2010 07:32:48 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274427168.33.0.755358354327.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

+   - If the name of an existing script is passed in ``argv[0]``, its absolute
+     path is prepended to :data:`sys.path`

Absolute path to the directory where script is located.  And I believe there's no absolute path guarantee for platforms without realpath / GetFullPathName.

Should the documentation also give some guidance to those that embed python and don't want to start using SetArgvEx right away and break compatibility with older python versions?  Something like:

If you're embedding python in your application, using SetArgv and don't want modified sys.path, call PyRun_SimpleString("sys.path.pop(0)\n"); after SysArgv to unconditionally drop the first sys.path argument added by SetArgv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Fri May 21 10:15:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 21 May 2010 08:15:36 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274429736.0.0.0189591110667.issue8765@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

This would require patching separately py2k and py3k visibly...
I'll have a look at it when I have time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Fri May 21 10:42:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 May 2010 08:42:45 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274431365.66.0.363293147539.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Alexander, I still don't understand your objection.  What's the downside of allowing the multiplication or division of a timedelta by a float?

Perhaps it's true that there are applications where timedeltas are best viewed as integers (with an implicitt 'microsecond' unit), but I think it's also true that there are plenty of applications where they're just regarded as a representation of a physical quantity, and there this proposal seems entirely appropriate.

I *would* want the timedelta * float and timedelta / float operations to be correctly rounded, so that behaviour is entirely predictable;  the current patch doesn't do that.  But it wouldn't be hard to implement:  there are functions available to express a float as a quotient of two integers, and after that the computation can be performed in integer arithmetic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Fri May 21 10:44:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 May 2010 08:44:49 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274431489.11.0.1845522634.issue8760@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do you have set the PYTHONHOME environment variable? this does not work from a build directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Fri May 21 11:04:49 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 21 May 2010 09:04:49 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1273877995.17.0.0354087541128.issue8720@psf.upfronthosting.co.za>
Message-ID: <1274432689.8.0.419832159819.issue8720@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

David, your getsourcefile.patch looks fine (and better than mine) to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Fri May 21 11:08:12 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 21 May 2010 09:08:12 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274432892.13.0.876672390138.issue8765@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

pakal wrote:
"""
In test_fileio, one of the tests wants to ensure writing to closed raw streams fails, but it actually tries to write an unicode string
"""

I don't understand. Isn't b'xxx' and 'xxx' the same in py2.x? They are not unicode string, but bytes string.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Fri May 21 11:22:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 May 2010 09:22:22 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274433742.72.0.438116536458.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Python reference implementation showing how to do correct rounding.

----------
Added file: http://bugs.python.org/file17426/timedelta_arith.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Fri May 21 11:29:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 09:29:04 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1274427168.33.0.755358354327.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274434139.3145.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Absolute path to the directory where script is located.  And I believe
> there's no absolute path guarantee for platforms without realpath /
> GetFullPathName.

Yes, this is more precise indeed. As for realpath(), I would expect it
to be present on modern Unices (man page says "4.4BSD, POSIX.1-2001").

> If you're embedding python in your application, using SetArgv and
> don't want modified sys.path, call
> PyRun_SimpleString("sys.path.pop(0)\n"); after SysArgv to
> unconditionally drop the first sys.path argument added by SetArgv.

I suppose 
  PyRun_SimpleString("import sys; sys.path.pop(0)\n");
would be better.
Thanks for the comments, I'll update the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Fri May 21 11:57:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 09:57:18 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1274435838.99.0.422696535292.issue4870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This was committed in r81392.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4870>
_______________________________________

From report at bugs.python.org  Fri May 21 12:05:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 May 2010 10:05:25 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274436325.08.0.0172233853982.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

N.B.  There's already logic for doing div_nearest (i.e., divide one integer by another, returning the closest integer to the result) in the long_round function in Objects/longobject.c.  It might be worth pulling that logic out and making it available in a _Py function so that it can be reused in other modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Fri May 21 12:06:28 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 21 May 2010 10:06:28 +0000
Subject: [issue8720] undo findsource regression/change
In-Reply-To: <1274432689.8.0.419832159819.issue8720@psf.upfronthosting.co.za>
Message-ID: <AANLkTiluOJWxW7rbvNlkpYXxnCRtiLJVLKPqtXSwSi-s@mail.gmail.com>


holger krekel <holger.krekel at gmail.com> added the comment:

Well, maybe we could introduce a "linecache.setlines" function to give
the linecache module control over its internal caching and data
handling. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8720>
_______________________________________

From report at bugs.python.org  Fri May 21 12:53:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 10:53:53 +0000
Subject: [issue8774] tabnanny improperly handles non-ascii source files
In-Reply-To: <1274325452.59.0.072847766153.issue8774@psf.upfronthosting.co.za>
Message-ID: <1274439233.99.0.468417593297.issue8774@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r81393 (py3k), r81394 (3.1).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8774>
_______________________________________

From report at bugs.python.org  Fri May 21 12:59:21 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 21 May 2010 10:59:21 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274439561.77.0.872678672584.issue8765@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

yes, but the same tests are used for py3k as well, where "xxx" is interpreted as unicode (2to3 tools dont try to guess if a py2k string intended to be a byte string or an unicode one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Fri May 21 13:02:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 11:02:46 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274439766.9.0.480800628887.issue8765@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

test_fileio and test_io both use "from __future__ import unicode_literals", which means classical string literals construct unicode strings rather than byte strings.
So, yes, Pascal is right, this should be corrected (both the tests, and the implementation so that it refuses unicode arguments).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Fri May 21 13:11:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 11:11:17 +0000
Subject: [issue4007] make clean fails to delete .a and .so.X.Y files
In-Reply-To: <1222865558.69.0.211492206559.issue4007@psf.upfronthosting.co.za>
Message-ID: <1274440277.92.0.759634173392.issue4007@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Yes, "make clean" should remove *.a and *.so.* files. The patch looks ok.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4007>
_______________________________________

From report at bugs.python.org  Fri May 21 13:26:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 11:26:41 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1274441201.95.0.480701545945.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> As you explain in your own documentation, the proposed method 
> is equivalent to ``(time.mktime(self.timetuple()), self.microsecond)``,
> so all it does is replacing a less than a one-liner.

a one-liner, but an horrible one liner :-) I don't like mixing datetime and time modules. I prefer to use only datetime, I prefer its API.

>  ... If the tzinfo of the datetime object does not match the 
> system TZ used by mktime, the result will be quite misleading.

Can you suggest a possible fix to take care of the timezone information? I don't know how to use that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 13:37:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 11:37:40 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1274441860.07.0.675362024741.issue2736@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with Victor that the APIs need improving, even if it involves providing obvious replacements of obscure one-liners. As an occasional user of datetime and time modules, I have too often wanted to curse those limited, awkwardly inconsistent APIs.

Just my 2 seconds of course :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 14:11:40 2010
From: report at bugs.python.org (Matthias Troffaes)
Date: Fri, 21 May 2010 12:11:40 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1274443900.69.0.34230908599.issue6695@psf.upfronthosting.co.za>


Changes by Matthias Troffaes <matthias.troffaes at gmail.com>:


Added file: http://bugs.python.org/file17427/py3k-rev81387-clearfreelist-dict_set_list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri May 21 14:12:17 2010
From: report at bugs.python.org (Matthias Troffaes)
Date: Fri, 21 May 2010 12:12:17 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1274443937.99.0.356658540733.issue6695@psf.upfronthosting.co.za>


Changes by Matthias Troffaes <matthias.troffaes at gmail.com>:


Added file: http://bugs.python.org/file17428/py3k-rev81387-clearfreelist-gc_collect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri May 21 14:12:56 2010
From: report at bugs.python.org (Matthias Troffaes)
Date: Fri, 21 May 2010 12:12:56 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1274443976.95.0.89925376301.issue6695@psf.upfronthosting.co.za>


Changes by Matthias Troffaes <matthias.troffaes at gmail.com>:


Added file: http://bugs.python.org/file17429/py3k-rev81387-clearfreelist-time_gc_collect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri May 21 14:30:47 2010
From: report at bugs.python.org (Matthias Troffaes)
Date: Fri, 21 May 2010 12:30:47 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1274445047.21.0.894100309576.issue6695@psf.upfronthosting.co.za>


Matthias Troffaes <matthias.troffaes at gmail.com> added the comment:

I uploaded updates of the three relevant patches against the current revision of the py3k branch, as the old patches no longer applied cleanly due to whitespace changes.

To summarize:

* The first patch, py3k-rev81387-clearfreelist-dict_set_list.patch, simply adds freelist methods to the public API for dict, list, and set. No opposition has been expressed against this, so I hope this can be accepted.

* The second patch, py3k-rev81387-clearfreelist-gc_collect.patch, adds calls to these methods to gc.collect() - some opposition was expressed against the (already present before my patch!!) method of freeing lists during highest generation garbage collection. I attempted to measure the actual time spent on freeing the freelists in a simply python program which does a lot of allocation (attached as py3k-freelist_test.py). This apparently shows that clearing the freelists does not affect timing much at all.

* The third patch, file py3k-rev81387-clearfreelist-time_gc_collect.patch, causes estimates of the time spent on freeing the freelists to be printed to the console, and is obviously for testing/benchmarking purpose only.

* The tp_free_list patch is no longer relevant (see comment by Guido).

Hoping for a conclusion of this issue,
Matthias

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri May 21 14:37:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 12:37:57 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code works on 2.6, 2.7 (trunk), 3.1, but not on py3k.

import subprocess, sys
subprocess.call([sys.executable, '-c', 'print("Hello World!")'])

On py3k, sys.stdout and sys.stderr are equal to... None.

I hope that it's a problem with my setup.

----------
components: Interpreter Core, Library (Lib)
messages: 106232
nosy: haypo
priority: normal
severity: normal
status: open
title: py3k: child process don't inherit stdout / stdout
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 14:38:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 12:38:30 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274445510.8.0.792729531077.issue8780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

("doesn't work" means that the example doesn't print anything)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 14:40:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 12:40:23 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274445623.74.0.572315229707.issue8780@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's just under Windows, right?

----------
assignee:  -> brian.curtin
components: +Windows
nosy: +brian.curtin, pitrou
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 14:44:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 12:44:00 +0000
Subject: [issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable
	(I think)
In-Reply-To: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>
Message-ID: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

If ./configure detects that the system's wchar_t type is compatible, it will define "#define PY_UNICODE_TYPE wchar_t" and enable certain optimizations when converting between Py_UNICODE and wchar_t (i.e., it can just do a memcpy).

Right now, ./configure considers wchar_t to be compatible if it is the same bit-width as Py_UNICODE and if wchar_t is unsigned.  In practice, that means Python only uses wchar_t on Windows, which uses an unsigned 16-bit wchar_t.  On Linux, wchar_t is 32-bit and signed.

In the original Unicode implementation for Python, Py_UNICODE was always 16-bit.  I believe the "unsigned" requirement heralds back to that time.  A 32-bit wchar_t gives us plenty of space to hold the maximum Unicode code point of 0x10FFFF, regardless of whether wchar_t is signed or unsigned.

I believe the condition could be relaxed to the following:
- wchar_t must be the same bit-width as Py_UNICODE, and
- if wchar_t is 16-bit, it must be unsigned

That would allow a UCS4 Python to use wchar_t on Linux.

I experimented by manually tweaking my pyconfig.h to treat Linux's signed 32-bit wchar_t as compatible.  The unit test suite encountered no problems.

However, it's quite possible that I'm missing some important detail here.  Someone familiar with the guts of Python's Unicode implementation  will presumably have a much better idea of whether I have this right or not. ;-)

----------
components: Interpreter Core, Unicode
messages: 106235
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8781>
_______________________________________

From report at bugs.python.org  Fri May 21 15:19:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 13:19:05 +0000
Subject: [issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable
	(I think)
In-Reply-To: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>
Message-ID: <1274447945.54.0.456108066249.issue8781@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem with a signed Py_UNICODE is implicit sign extension (rather than zero extension) in some conversions, for example from "char" or "unsigned char" to "Py_UNICODE". The effects could go anywhere from incorrect results to plain crashes. Not only in our code, but in C extensions relying on the unsignedness of Py_UNICODE.

Is there a way to enable those optimizations while keeping an unsigned Py_UNICODE type? It seems Py_UNICODE doesn't have to be typedef'ed to wchar_t, it can be defined to be an unsigned integer of the same width. Or would it break some part of the C standard?

----------
nosy: +lemburg, loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8781>
_______________________________________

From report at bugs.python.org  Fri May 21 15:20:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 13:20:10 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout on
	Windows
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274448010.97.0.784995597811.issue8780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It's just under Windows, right?

It works on Linux. I suppose that the issue is specific to Windows.

----------
title: py3k: child process don't inherit stdout / stdout -> py3k: child process don't inherit stdout / stdout on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 15:37:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 13:37:35 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout on
	Windows
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274449055.72.0.0698619224741.issue8780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Recent change of subprocess in py3k, I don't know if it's related: r78946.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 15:45:17 2010
From: report at bugs.python.org (Orlando Irrazabal)
Date: Fri, 21 May 2010 13:45:17 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274431489.11.0.1845522634.issue8760@psf.upfronthosting.co.za>
Message-ID: <4BF68E67.4080105@mendoza.gov.ar>


Orlando Irrazabal <oirraza at mendoza.gov.ar> added the comment:

Amoury, you are right, when i unset the PYTHONHOME environment variable 
the program run. The output was:

root at host:python-2.6.5# ./python -m test.regrtest -w
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
test_unittest
test_doctest
test_doctest skipped -- No module named thread
test_doctest2
test_MimeWriter
test_SimpleHTTPServer
test_StringIO
test___all__
test___future__
test__locale
test_abc
test_abstract_numbers
test_aepack
test_aepack skipped -- No module named aepack
test_aifc
test_al
test_al skipped -- No module named al
test_anydbm
test_applesingle
test_applesingle skipped -- No module named macostools
test_array
test_ast
test_asynchat
test_asynchat skipped -- No module named thread
test_asyncore
test_asyncore skipped -- No module named thread
test_atexit
test_audioop
test_augassign
test_base64
test_bastion
test_bigaddrspace
test_bigmem
test_binascii
test_binhex
test_binop
test_bisect
test_bool
test_bsddb
test_bsddb skipped -- No module named _bsddb
test_bsddb185
test_bsddb185 skipped -- No module named bsddb185
test_bsddb3
test_bsddb3 skipped -- Use of the `bsddb' resource not enabled
test_buffer
test_bufio
test_bytes
test_bz2
test_bz2 skipped -- No module named thread
test_calendar
test_call
test_capi
test_capi skipped -- No module named thread
test_cd
test_cd skipped -- No module named cd
test_cfgparser
test_cgi
test_charmapcodec
test_cl
test_cl skipped -- No module named cl
test_class
test_cmath
test test_cmath failed -- Traceback (most recent call last):
   File "/sw_install/python-2.6.5/Lib/test/test_cmath.py", line 366, in 
test_specific_values
     self.fail(error_message)
AssertionError: atan0000: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.

test_cmd
test_cmd skipped -- No module named thread
test_cmd_line
test_cmd_line_script
test_code
test_codeccallbacks
test_codecencodings_cn
test_codecencodings_hk
test_codecencodings_jp
test_codecencodings_kr
test_codecencodings_tw
test_codecmaps_cn
test_codecmaps_cn skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_hk
test_codecmaps_hk skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_jp
test_codecmaps_jp skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_kr
test_codecmaps_kr skipped -- Use of the `urlfetch' resource not enabled
test_codecmaps_tw
test_codecmaps_tw skipped -- Use of the `urlfetch' resource not enabled
test_codecs
test_codeop
test_coding
test_coercion
test_collections
test_colorsys
test_commands
test_compare
test_compile
test_compiler
test_complex
test_complex_args
test_contains
test_contextlib
test_contextlib skipped -- No module named thread
test_cookie
test_cookielib
test_copy
test_copy_reg
test_cpickle
Exception RuntimeError: 'maximum recursion depth exceeded in 
__subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
test test_cpickle failed -- multiple errors occurred; run in verbose 
mode for details
test_cprofile
test_crypt
test_csv
test_ctypes
test_ctypes skipped -- No module named _ctypes
test_curses
test_curses skipped -- No module named _curses_panel
test_datetime
test_dbm
test_decimal
test_decorators
test_defaultdict
test_deque
test_descr
test_descrtut
test_difflib
test_dircache
test_dis
test_distutils
unable to execute ./Modules/ld_so_aix: No such file or directory
test test_distutils failed -- Traceback (most recent call last):
   File 
"/sw_install/python-2.6.5/Lib/distutils/tests/test_build_ext.py", line 
261, in test_get_outputs
     cmd.run()
   File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", 
line 340, in run
     self.build_extensions()
   File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", 
line 449, in build_extensions
     self.build_extension(ext)
   File "/sw_install/python-2.6.5/Lib/distutils/command/build_ext.py", 
line 531, in build_extension
     target_lang=language)
   File "/sw_install/python-2.6.5/Lib/distutils/ccompiler.py", line 769, 
in link_shared_object
     extra_preargs, extra_postargs, build_temp, target_lang)
   File "/sw_install/python-2.6.5/Lib/distutils/unixccompiler.py", line 
258, in link
     raise LinkError, msg
LinkError: command './Modules/ld_so_aix' failed with exit status 1

test_dl
test_dl skipped -- Could not open any shared libraries
test_docxmlrpc
test_docxmlrpc skipped -- No module named thread
test_dumbdbm
test_dummy_thread
test_dummy_threading
test_email
test_email_codecs
test_email_renamed
test_enumerate
test_eof
test_epoll
test_epoll skipped -- test works only on Linux 2.6
test_errno
test_exception_variations
test_extcall
test_fcntl
test_file
test_file skipped -- No module named thread
test_filecmp
test_fileinput
test_fileio
test test_fileio failed -- Traceback (most recent call last):
   File "/sw_install/python-2.6.5/Lib/test/test_fileio.py", line 157, in 
testAbles
     self.assertEquals(f.seekable(), False)
AssertionError: True != False

test_float
test_fnmatch
test_fork1
test_fork1 skipped -- No module named thread
test_format
test_fpformat
test_fractions
test_frozen
test_ftplib
test_ftplib skipped -- No module named thread
test_funcattrs
test_functools
test_future
test_future3
test_future4
test_future5
test_future_builtins
test_gc
test_gdbm
test_gdbm skipped -- No module named gdbm
test_generators
test_genericpath
test_genexps
test_getargs
test_getargs2
test_getopt
test_gettext
test_gl
test_gl skipped -- No module named gl
test_glob
test_global
test_grp
test_gzip
test_hash
test_hashlib
test_heapq
test_hmac
test_hotshot
Segmentation fault (core dumped)

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Fri May 21 15:55:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 13:55:05 +0000
Subject: [issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable
	(I think)
In-Reply-To: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>
Message-ID: <1274450105.57.0.555651103047.issue8781@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Usually you wouldn't want to cast a char directly to a Py_UNICODE, because you need to take into account the encoding of the char and map it to the appropriate Unicode character.  The exception is when you're certain the char is 7-bit ASCII, which is a subset of Unicode; that's safe since 7-bit ASCII never uses the sign bit.

However, again, I'm not an expert on the internals of Python's Unicode implementation and it's possible that I'm missing something.  ;) You also raise a good point about third-party code.

Your other suggestion is quite workable.  ./configure could define HAVE_USABLE_WCHAR_T (which is used to enable the optimizations) when sizeof(wchar_t) == sizeof(Py_UNICODE), yet still define Py_UNICODE as unsigned.  Using Google Code I could not find any instances of HAVE_USABLE_WCHAR_T being used outside of CPython itself.

Another option would be to test Py_UNICODE_SIZE == SIZEOF_WCHAR_T to enable the optimizations, instead of defined(HAVE_USABLE_WCHAR_T).  The plus side is that we wouldn't be changing the semantics of anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8781>
_______________________________________

From report at bugs.python.org  Fri May 21 15:59:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 13:59:26 +0000
Subject: [issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable
	(I think)
In-Reply-To: <1274450105.57.0.555651103047.issue8781@psf.upfronthosting.co.za>
Message-ID: <1274450361.3145.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Another option would be to test Py_UNICODE_SIZE == SIZEOF_WCHAR_T to
> enable the optimizations, instead of defined(HAVE_USABLE_WCHAR_T).
> The plus side is that we wouldn't be changing the semantics of
> anything.

I guess it's sufficient, indeed.
Besides, the optimizations don't really seem to be used in any critical
paths anyway...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8781>
_______________________________________

From report at bugs.python.org  Fri May 21 16:05:32 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 14:05:32 +0000
Subject: [issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable
	(I think)
In-Reply-To: <1274445840.82.0.641304229797.issue8781@psf.upfronthosting.co.za>
Message-ID: <1274450732.07.0.0604052162308.issue8781@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Yeah, this is a "I noticed this small optimization while working on something else" kind of thing. ;) ("something else" being Issue8654)

I can make a patch to change the #if's to test Py_UNICODE_SIZE == SIZEOF_WCHAR_T, though I'll give others a few days to chime in first.

----------
assignee:  -> stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8781>
_______________________________________

From report at bugs.python.org  Fri May 21 16:08:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 May 2010 14:08:37 +0000
Subject: [issue8760] Python 2.6.5 fails to build on AIX 5.3
In-Reply-To: <1274221853.63.0.90590760776.issue8760@psf.upfronthosting.co.za>
Message-ID: <1274450917.9.0.690513160074.issue8760@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Closing as Invalid. PYTHONHOME should not be set when building Python.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8760>
_______________________________________

From report at bugs.python.org  Fri May 21 16:12:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 14:12:59 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout on
	Windows
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274451179.71.0.116042712477.issue8780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, it *is* a regression introduced by r78946. Attached patch fixes the issue and adds a regression test.

Add also the author of r78946 to the nosy list :-)

----------
keywords: +patch
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file17430/subprocess_windows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 16:34:09 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 21 May 2010 14:34:09 +0000
Subject: [issue8782] inspect.getsource returns invalid source for
	non-newline-ending module
In-Reply-To: <1274452449.06.0.949392077471.issue8782@psf.upfronthosting.co.za>
Message-ID: <1274452449.06.0.949392077471.issue8782@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Executing the attached "inspect_failure.py" under python2.6 or python3.1 results in an assertion error: Python fails to obtain the source code of a function that is defined at the end of a module whose last line does not contain a line ending character. 

After brief analysis i think there are two approaches to fixing it: normalizing newlines in inspect.findsource (see attached inspect.patch file against r312) or performing normalization in linecache.updatecache which does it already for source code obtained from PEP302 loaders. Or any other ideas?

----------
files: inspect.patch
keywords: patch
messages: 106245
nosy: hpk
priority: normal
severity: normal
status: open
title: inspect.getsource returns invalid source for non-newline-ending module
type: behavior
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/file17431/inspect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8782>
_______________________________________

From report at bugs.python.org  Fri May 21 16:46:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 21 May 2010 14:46:36 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stdout on
	Windows
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274453196.7.0.617075308723.issue8780@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Looks fine to me.

The first line of the test comment has "if" instead of "is" but you could fix that on checkin.

----------
assignee: brian.curtin -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 16:57:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 May 2010 14:57:48 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274453868.33.0.0438142187368.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

py3k patch applied in r81397, with some tweaks:
 - fix reference leak (j wasn't being Py_DECREF'd in the long branch)
 - remove trailing whitespace
 - put 'else' and 'else if' on a new line following a closing brace
 - remove unnecessary NULL initializations
 - minor simplifications to long branch

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Fri May 21 17:14:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 May 2010 15:14:01 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274454841.43.0.85273980696.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  The current Python 2.7 behaviour really is a mess.

Your patch removes the coercion entirely;  I'm not sure that's a good idea:  mightn't this change behaviour for user-defined classes with a __coerce__ method?  Maybe it would be better to just special-case ints and longs at the start of complex_richcompare, and then leave everything else more-or-less intact?

I'm beginning to wonder whether it's actually worth fixing this at all in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Fri May 21 17:20:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 15:20:32 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1274441201.95.0.480701545945.issue2736@psf.upfronthosting.co.za>
Message-ID: <AANLkTin4xxeYlXNIo_bqFz21ABrfoMYm2JjcR-9N4iCk@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, May 21, 2010 at 7:26 AM, STINNER Victor <report at bugs.python.org> wrote:
..
>> ?... If the tzinfo of the datetime object does not match the
>> system TZ used by mktime, the result will be quite misleading.
>
> Can you suggest a possible fix to take care of the timezone information? I don't know how to use that.

I believe it should be something like this:

from claendar import timegm
def datetime_totimestamp(dt):
    return timegm(dt.utctimetuple()), dt.microsecond)

Note the following comment in the documentation for tzinfo.fromutc():
"An example of a time zone the default fromutc() implementation may
not handle correctly in all cases is one where the standard offset
(from UTC) depends on the specific date and time passed, which can
happen for political reasons.  The default implementations of
astimezone() and fromutc() may not produce the result you want if the
result is one of the hours straddling the moment the standard offset
changes."  I have not tested the above code and it may not work for
non-trivial time-zones.

Still a few questions remain:

1. Should absence of tzinfo imply local timezone or UTC?
2. Given that datetime.fromtimestamp() takes an optional tz argument,
should totimestamp() do the same and use given tz for naive datetime
objects?
3. Should there be a toutctimestamp()?

I believe at this stage we need a python implementation of a prototype
answering these questions and a unit test that would demonstrate how
the prototype would work with nontrivial timezones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 17:26:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 15:26:04 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1274455564.5.0.861527319056.issue6695@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri May 21 17:29:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 15:29:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274455760.98.0.655106196096.issue6715@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri May 21 18:03:54 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 16:03:54 +0000
Subject: [issue8750] Many of MutableSet's methods assume that the other
	parameter is not self
In-Reply-To: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>
Message-ID: <1274457834.79.0.676597117944.issue8750@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Patch with unit test attached for MutableSet's:

x ^= x
x -= x

I was wrong about |= and &= having a problem.  Since they don't mutate the set, they don't raise an exception (they only .add items that are already in the set).  I added tests for them but left the implementation alone.

----------
keywords: +needs review, patch
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file17432/set-isub.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8750>
_______________________________________

From report at bugs.python.org  Fri May 21 18:06:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 16:06:08 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1274441860.07.0.675362024741.issue2736@psf.upfronthosting.co.za>
Message-ID: <AANLkTilqa2e3wW2V3iiv_ZUtJnWGsubcCq7EM-MF8aiJ@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, May 21, 2010 at 7:37 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> I agree with Victor that the APIs need improving, even if it involves providing obvious replacements of obscure one-liners.

While I agree that the datetime API can be improved, I don't think
Victor's proposal does that.  The advantage of an obscure one-liner is
that it is obvious what it does, particularly for someone with a
C/UNIX background.  dt.totimestamp() may be easier to write, but it is
entirely non-obvious what it will return.  One would expect that
dt.totimestamp() is the inverse of datetime.fromtimestamp(timestamp),
but in timezones with daylight savings adjustments, but such inverse
may not always exist.  (01:59AM may be followed by 02:00 AM or by
01:00 AM. so on changeover days datetime(y, m, d, 1, 30).totimestamp()
is either ambiguous or undefined.)   As I suggested in my previous
comment, this problem can be resolved, but we are not there yet.

> As an occasional user of datetime and time modules, I have too often wanted to curse those limited, awkwardly inconsistent APIs.

Yes, it would be ideal if a user of datetime module would not need to
reach to other modules for date/time calculations.  See also
<http://bugs.python.org/issue6280>.   Do you have other examples of
this sort?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 18:08:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 16:08:13 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1274458093.49.0.464897156733.issue2736@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy:  -Alexander.Belopolsky
stage:  -> unit test needed
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 18:10:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 16:10:56 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <AANLkTin4xxeYlXNIo_bqFz21ABrfoMYm2JjcR-9N4iCk@mail.gmail.com>
Message-ID: <AANLkTilm4WFH173dMH6i3KBlyB-rAC9QqitHdWiDW3N2@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, May 21, 2010 at 11:20 AM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> I believe it should be something like this:
>
> from claendar import timegm

s/claendar/calendar/, of course.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 18:18:30 2010
From: report at bugs.python.org (Meador Inge)
Date: Fri, 21 May 2010 16:18:30 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1274458710.28.0.0577934974042.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Hmm.  The current Python 2.7 behaviour really is a mess.

No doubt!

> Your patch removes the coercion entirely;  

Yeah, I know.  The funny thing about this is that according to the documentation [1]:

   "Arguments to rich comparison methods are never coerced."

> I'm not sure that's a good idea:  mightn't this change behaviour for 
> user-defined classes with a __coerce__ method?  Maybe it would be 
> better to just special-case ints and longs at the start of 
> complex_richcompare, and then leave everything else more-or-less 
> intact?

I will look into that today.

> I'm beginning to wonder whether it's actually worth fixing this at all > in 2.7.

:)

[1] http://docs.python.org/dev/reference/datamodel.html#basic-customization

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Fri May 21 18:20:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 16:20:23 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1274458823.28.0.23347267556.issue2736@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The advantage of an obscure one-liner is
> that it is obvious what it does, particularly for someone with a
> C/UNIX background.

Well, I would argue that the C/Unix legacy in terms of dates and times isn't an example to follow. Python does not force you to use strcat() to concatenate strings, either ;)

But besides, the issue is more how people are supposed to invent that one-liner, let alone remember it easily. Perhaps adding it in the documentation would be a good middle ground, if you think it shouldn't be added to the stdlib.

> Do you have other examples of this sort?

Well, for example, the datetime module encourages you to use "aware" datetime objects (rather than so-called "naive" objects), but there isn't a single facility to do so. You must reinvent a whole timezone class from scratch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 18:25:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 16:25:13 +0000
Subject: [issue5288] tzinfo objects with sub-minute offsets are not supported
	(e.g. UTC+05:53:28)
In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
Message-ID: <1274459113.86.0.972735594231.issue5288@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky
stage:  -> unit test needed
type:  -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5288>
_______________________________________

From report at bugs.python.org  Fri May 21 18:44:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 16:44:04 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1274458823.28.0.23347267556.issue2736@psf.upfronthosting.co.za>
Message-ID: <AANLkTinDykzAdZ3OL94nJcip-J0LKZNQ2V4YLUNIMj8r@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, May 21, 2010 at 12:20 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> Well, for example, the datetime module encourages you to use "aware" datetime objects (rather than so-called "naive" objects),
> but there isn't a single facility to do so. You must reinvent a whole timezone class from scratch.

This is partially addressed by issue 5094, "datetime lacks concrete
tzinfo impl. for UTC".  A more ambitious project would be to add pytz
to stdlib.  I believe I've seen this idea discussed and rejected, but
I am not able to find a link to an appropriate thread now.  A half-way
project would be to add LocalTimezone given as an example in
http://docs.python.org/dev/py3k/library/datetime.html in addition for
UTC timezone.   Any takers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri May 21 18:44:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 16:44:35 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274460275.68.0.426531282583.issue5094@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Fri May 21 18:51:49 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 21 May 2010 16:51:49 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1274460709.59.0.0268187746844.issue1621@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Fri May 21 19:41:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 May 2010 17:41:01 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1274463661.05.0.139346755287.issue5753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r81398 (trunk), r81399 (2.6), r81400 (py3k), r81401 (3.1). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Fri May 21 20:57:18 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 18:57:18 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274468238.47.0.857629819948.issue8729@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Here is a revised patch based on Benjamin's comments on Rietveld.

----------
Added file: http://bugs.python.org/file17433/mapping2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Fri May 21 21:58:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 19:58:06 +0000
Subject: [issue1436346] yday in datetime module
In-Reply-To: <1274398033.3141.5.camel@localhost.localdomain>
Message-ID: <AANLkTilXguCd7NVAO0XROvhIMOQGzwU9ZMpmJN1FJnrd@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, May 20, 2010 at 7:27 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
>> ..?The OP's premise was that
>> t.timetuple()[7] was unreadable, but in the modern python, the same
>> can be written as t.timetuple().tm_yday.
>
> Could I suggest such example be added to the documentation, though?

The documentation for timetuple method [1, 2] already contains a
recipe for computing yday which is more efficient than
t.timetuple().tm_yday:

 yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1

Maybe it can be improved by making it discoverable in searches for yday:

"""
... is equivalent to time.struct_time((d.year, d.month, d.day, d.hour,
d.minute, d.second, d.weekday(), yday, dst)), where yday =
d.toordinal() - date(d.year, 1, 1).toordinal() + 1 is the day number
of the year starting from 1 for January 1st.
"""

[1] http://docs.python.org/py3k/library/datetime.html#datetime.date.timetuple
[2] http://docs.python.org/py3k/library/datetime.html#datetime.datetime.timetuple

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri May 21 22:05:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 May 2010 20:05:58 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274472358.77.0.854345807947.issue1436346@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Fri May 21 22:09:38 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 20:09:38 +0000
Subject: [issue8783] The external link to a "Hash Collision FAQ" points to
	some company's homepage
In-Reply-To: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>
Message-ID: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

At the bottom of the documentation for hashlib, there's a link to
http://www.cryptography.com/cnews/hash.html

which the hashlib documentation describes as "Hash Collision FAQ with information on which algorithms have known issues and what that means regarding their use."

However, the page at that link is identical to http://www.cryptography.com/

which is just the homepage of some company that happens to deal with cryptography.  If they do in fact host a Hash Collision FAQ, I couldn't find it. :-(

Googling for "Hash Collision FAQ" (with quotes) mostly turns up references to the Python documentation, so I'm guessing the intended document no longer exists.

The following wikipedia link might be an OK substitute, although it makes for pretty dense reading.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms

----------
assignee: docs at python
components: Documentation
messages: 106259
nosy: docs at python, stutzbach
priority: normal
severity: normal
status: open
title: The external link to a "Hash Collision FAQ" points to some company's homepage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8783>
_______________________________________

From report at bugs.python.org  Fri May 21 22:23:14 2010
From: report at bugs.python.org (=?utf-8?q?Adomas_Paltanavi=C4=8Dius?=)
Date: Fri, 21 May 2010 20:23:14 +0000
Subject: [issue1621421] normalize namespace from minidom
Message-ID: <1274473394.47.0.747632755249.issue1621421@psf.upfronthosting.co.za>


Changes by Adomas Paltanavi?ius <adomas.paltanavicius at gmail.com>:


----------
nosy: +admp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621421>
_______________________________________

From report at bugs.python.org  Fri May 21 22:25:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:25:50 +0000
Subject: [issue8783] The external link to a "Hash Collision FAQ" points to
	some company's homepage
In-Reply-To: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>
Message-ID: <1274473550.7.0.695224394923.issue8783@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The FAQ can still be found in the internet archive, http://web.archive.org/web/20070928160638/http://www.cryptography.com/cnews/hash.html

but of course this is not a good link, especially because it's not updated.  I've added the link to the wikipedia article, as you suggested, in r81404.  It should be a good starting point for further research.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8783>
_______________________________________

From report at bugs.python.org  Fri May 21 22:36:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:36:36 +0000
Subject: [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1274474196.85.0.450034618478.issue8694@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This was due to a review of the programming FAQ not yet having been merged to the 3.1 branch.  Now fixed in r81407.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8694>
_______________________________________

From report at bugs.python.org  Fri May 21 22:38:46 2010
From: report at bugs.python.org (Christophe Simonis)
Date: Fri, 21 May 2010 20:38:46 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274474326.74.0.334105048016.issue6715@psf.upfronthosting.co.za>


Changes by Christophe Simonis <simonis.christophe at gmail.com>:


----------
nosy: +Christophe Simonis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri May 21 22:39:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:39:55 +0000
Subject: [issue8691] Doc: left alignment is not the default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1274474395.68.0.778262574436.issue8691@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Eric should know the exact semantics best.

----------
assignee: docs at python -> eric.smith
nosy: +eric.smith, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8691>
_______________________________________

From report at bugs.python.org  Fri May 21 22:40:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 20:40:58 +0000
Subject: [issue8780] py3k: child process don't inherit stdout / stderr on
	Windows
In-Reply-To: <1274445476.8.0.294880351172.issue8780@psf.upfronthosting.co.za>
Message-ID: <1274474458.03.0.177731571007.issue8780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r81403 (py3k).

Even if the issue is a regression specific to 3.x, I backported the new test in 3.1: r81408.

----------
resolution:  -> fixed
status: open -> closed
title: py3k: child process don't inherit stdout / stdout on Windows -> py3k: child process don't inherit stdout / stderr on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8780>
_______________________________________

From report at bugs.python.org  Fri May 21 22:52:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 May 2010 20:52:37 +0000
Subject: [issue8729] The Mapping ABC's __eq__ method should return
	NotImplemented if the other type is not a Mapping
In-Reply-To: <1273961292.4.0.504404217276.issue8729@psf.upfronthosting.co.za>
Message-ID: <1274475157.99.0.638181688565.issue8729@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81414. Thanks for the patch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8729>
_______________________________________

From report at bugs.python.org  Fri May 21 22:58:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:58:56 +0000
Subject: [issue8724] bind_and_activate parameter is missed from directive
In-Reply-To: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>
Message-ID: <1274475536.42.0.241376283556.issue8724@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r81419.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8724>
_______________________________________

From report at bugs.python.org  Fri May 21 23:30:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 21:30:53 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1274477453.89.0.0482876396748.issue4769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached base64_main.patch fixes errors described in b64-decode-str-bytes-typeerror.txt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Fri May 21 23:30:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 21:30:58 +0000
Subject: [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274477458.0.0.707563232343.issue8707@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r81431.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8707>
_______________________________________

From report at bugs.python.org  Fri May 21 23:32:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 May 2010 21:32:02 +0000
Subject: [issue8782] inspect.getsource returns invalid source for
	non-newline-ending module
In-Reply-To: <1274452449.06.0.949392077471.issue8782@psf.upfronthosting.co.za>
Message-ID: <1274477522.2.0.640864215202.issue8782@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81432 by making linecache smarter.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8782>
_______________________________________

From report at bugs.python.org  Sat May 22 00:03:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:03:46 +0000
Subject: [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1274479426.19.0.715739790278.issue8709@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r81450.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8709>
_______________________________________

From report at bugs.python.org  Sat May 22 00:56:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 22:56:17 +0000
Subject: [issue5640] Wrong print() result when unicode error handler is not
	'strict'
In-Reply-To: <1238571303.14.0.143713902199.issue5640@psf.upfronthosting.co.za>
Message-ID: <1274482577.55.0.141446897555.issue5640@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Hyeshik Chang commited the fix one year ago in py3k (r71045).

I ported the fix to trunk (r81454) and 2.6 (r81456).

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5640>
_______________________________________

From report at bugs.python.org  Sat May 22 01:36:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 23:36:34 +0000
Subject: [issue3798] SystemExit incorrectly displays unicode message
In-Reply-To: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>
Message-ID: <1274484994.03.0.545083066053.issue3798@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch for trunk. This bug is minor, and so I don't know if it can be commited to 2.7.

The patch adds also a test that I added to py3k in r81252:

"handle_system_exit() flushs files to warranty the output order

PyObject_Print() writes into the C object stderr, whereas PySys_WriteStderr() writes into the Python object sys.stderr. Each object has its own buffer, so call sys.stderr.flush() and fflush(stderr)."

----------
keywords: +patch
nosy: +benjamin.peterson, haypo
Added file: http://bugs.python.org/file17434/handle_system_exit_unicode-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3798>
_______________________________________

From report at bugs.python.org  Sat May 22 01:46:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 23:46:57 +0000
Subject: [issue3798] SystemExit incorrectly displays unicode message
In-Reply-To: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>
Message-ID: <1274485617.78.0.349106682792.issue3798@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I applied a similar patch to py3k (r81457) to use sys.stderr encoding and error handler, instead of the default encoding (utf8).

Wait for the buildbot before backporting to 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3798>
_______________________________________

From report at bugs.python.org  Sat May 22 01:54:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2010 23:54:46 +0000
Subject: [issue3297] Python interpreter uses Unicode surrogate pairs only
	before the pyc is created
In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za>
Message-ID: <1274486086.23.0.89829111981.issue3297@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@benjamin.peterson: Do you plan to port r75928 to 2.7 and 3.1? If not, can you close this issue?

I think that this issue priority is minor because few people write directly non-BMP characters in Python files (maybe only one, Ezio Melotti :-)). u"\uxxxx", u"\Uxxxxxxxx" or unichr(xxx) can be used in Python 2.7 and 3.1 (without u prefix for 3.1).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3297>
_______________________________________

From report at bugs.python.org  Sat May 22 02:03:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 00:03:15 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1274486595.51.0.0374795407903.issue6058@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Would it be possible to implement a "cp65001" codec in Python using MultiByteToWideChar() / WideCharToMultiByte() with codepage=CP_UTF8?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Sat May 22 03:01:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:01:38 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1274490098.19.0.320617357249.issue850997@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat May 22 03:10:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:10:42 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1274490642.43.0.342551172095.issue7768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug is fixed in Python3. I would like to say that you should use Python3 (which has a much better unicode support) instead of Python2 to get such feature, and that this issue should be closed (as wontfix).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Sat May 22 03:22:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:22:15 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

mbcs encoding replace non encodable characters (loose information) and doesn't support surrogateescape error handler. It ignores the error handler argument: see #850997, and tarfile now uses surrogateescape error handler by default (#8390). This encoding is just horrible for unicode support :-)

Since Windows native API use unicode character (UTF-16), I think that it would be better to use utf-8 for the default encoding on Windows. utf-8 is able to encode and decode the full Unicode charset and supports all error handlers (especially surrogateescape).

Attached patch sets the default encoding to utf-8 on Windows, and removes the test ENCODING is None because sys.getfilesystemencoding() cannot be None anymore (in 3.2 only, it's a recent change: #8610).

----------
components: Library (Lib), Unicode, Windows
files: tarfile_windows_utf8.patch
keywords: patch
messages: 106276
nosy: haypo, lars.gustaebel
priority: normal
severity: normal
status: open
title: tarfile/Windows: Don't use mbcs as the default encoding
versions: Python 3.2
Added file: http://bugs.python.org/file17435/tarfile_windows_utf8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Sat May 22 03:36:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:36:16 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1274492176.31.0.938033584889.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I patched py3k with mbcs_errors.patch (only encode_mbcs, not the decoder function) and most test pass: I opened #8784 for test_tarfile failure.

I don't think that it's a problem that mbcs only supports few error handlers, eg. 'strict', 'replace' and 'errors' (but not 'ignore' nor 'surrogateescape'). mbcs should be avoided anyway :-) It is kept for backward compatibility (with Python2). Python3 tries to avoid it by using the Unicode functions of Windows API.

I don't know exactly where mbcs is still used in Python3. If mbcs becomes more strict and raise new errors, I would like to say that the problem comes from the program, not in the encodig, and the program should be fixed (especilly if the "program" is the Python standard library).

About the backward compatibility with Python < 3.2: I don't know exactly if this change would be a problem or not. I bet that few people use (directly or indirectly) mbcs with Python 3.1 (on Windows), and few peple (or nobody) would notice this change. And as I wrote, if someone notices a problem: the problem should be fixed in the function using mbcs, not in the codec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat May 22 03:38:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:38:51 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1274492331.25.0.0781765172589.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since this change breaks backward compatibility, it's a very bad idea to change mbcs codec in Python 2.7: remove this version from this issue.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Sat May 22 03:41:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:41:33 +0000
Subject: [issue1436203] getpass.getpass() should allow Unicode prompts
Message-ID: <1274492493.92.0.075401094551.issue1436203@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

As I wrote in issue #7768: this issue is already fixed in Python3 (getpass supports unicode prompt) and you should use Python3 instead of Python2 because Python3 has a much better unicode support. It would be harder to fix Python2, and this issue has no patch. Since we are close to 2.7rc1 (and 2.7 should be the last major version of the 3.x branch), I would like to say that this issue should be closed as "wontfix".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436203>
_______________________________________

From report at bugs.python.org  Sat May 22 03:42:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:42:31 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1274492551.19.0.919864044529.issue7768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"and that this issue should be closed (as wontfix)."

... because this issue has no patch and we are close to 2.7rc1 (and 2.7 should be the last major version of the 3.x branch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Sat May 22 03:43:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:43:41 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1274492621.24.0.490084930272.issue7983@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Sat May 22 03:50:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 01:50:20 +0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1274493020.0.0.131039127886.issue2027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Before having a optimized version of common test algorithms, why not starting by a Python? Write and maintain C code is harder, and I'm not sure that performances are critical for such algorithm.

This issue has no patch: if nobody provides a patch, I will close it because I agree with Amaury and Christian (this issue can be solved by an 3rd party module: such module can be written in C).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
_______________________________________

From report at bugs.python.org  Sat May 22 04:18:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 02:18:01 +0000
Subject: [issue6268] Seeking to the beginning of a text file a second time
	will return the BOM as first character
In-Reply-To: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>
Message-ID: <1274494681.36.0.785646011496.issue6268@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed: 2.7 (r81459), 2.6 (r81460), 3.2 (r81461), 3.1 (r81462).

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6268>
_______________________________________

From report at bugs.python.org  Sat May 22 04:19:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 02:19:10 +0000
Subject: [issue6268] Seeking to the beginning of a text file a second time
	will return the BOM as first character
In-Reply-To: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>
Message-ID: <1274494750.81.0.412785918015.issue6268@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(For your information, io module had the same problem in Python3: it was fixed in #4862)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6268>
_______________________________________

From report at bugs.python.org  Sat May 22 06:08:35 2010
From: report at bugs.python.org (Alberto Trevino)
Date: Sat, 22 May 2010 04:08:35 +0000
Subject: [issue8739] Update to smtpd.py to RFC 5321
In-Reply-To: <1274363203.34.0.29483337537.issue8739@psf.upfronthosting.co.za>
Message-ID: <201005212208.30291.alberto@byu.edu>


Alberto Trevino <alberto at byu.edu> added the comment:

On Thursday 20 May 2010 07:46:43 am you wrote:
> If you don't specify the size, the response of EHLP won't list
> SIZE as one of the extensions.  But, if a size is specified, then it
> will show it on EHLP.

Sorry, the EHLP above should be EHLO.  Fat fingers, little sleep, talk about 
help... you get the idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8739>
_______________________________________

From report at bugs.python.org  Sat May 22 09:46:55 2010
From: report at bugs.python.org (holger krekel)
Date: Sat, 22 May 2010 07:46:55 +0000
Subject: [issue8782] inspect.getsource returns invalid source for
	non-newline-ending module
In-Reply-To: <1274477522.2.0.640864215202.issue8782@psf.upfronthosting.co.za>
Message-ID: <AANLkTilSLoC505RHQ1ixJRHk7mLQNMxCAC8dj2xEA1aU@mail.gmail.com>


holger krekel <holger.krekel at gmail.com> added the comment:

Great. Also to be backported to 2.x?

holger

On Fri, May 21, 2010 at 11:32 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> Fixed in r81432 by making linecache smarter.
>
> ----------
> nosy: +benjamin.peterson
> resolution: ?-> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8782>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8782>
_______________________________________

From report at bugs.python.org  Sat May 22 09:54:18 2010
From: report at bugs.python.org (Sebastian Rittau)
Date: Sat, 22 May 2010 07:54:18 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1274514858.3.0.821952226438.issue2736@psf.upfronthosting.co.za>


Changes by Sebastian Rittau <srittau at jroger.in-berlin.de>:


----------
nosy:  -srittau

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Sat May 22 10:03:34 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 22 May 2010 08:03:34 +0000
Subject: [issue8785] findall() and finditer() docs misleading
In-Reply-To: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>
Message-ID: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The docs for the RegexpObject methods findall and finditer are misleading: They are said to behave the same way as the respective functions, but in fact the parameter semantics are different.

----------
assignee: docs at python
components: Documentation
messages: 106286
nosy: docs at python, hagen
priority: normal
severity: normal
status: open
title: findall() and finditer() docs misleading
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8785>
_______________________________________

From report at bugs.python.org  Sat May 22 10:19:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 May 2010 08:19:02 +0000
Subject: [issue8785] findall() and finditer() docs misleading
In-Reply-To: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>
Message-ID: <1274516342.25.0.0753830077475.issue8785@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r81463.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8785>
_______________________________________

From report at bugs.python.org  Sat May 22 10:21:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 May 2010 08:21:24 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274516484.08.0.986834256184.issue1436346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Care to suggest a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Sat May 22 10:51:18 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sat, 22 May 2010 08:51:18 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274518278.27.0.0333705738051.issue8765@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Yes, I saw that, thanks for explanation!

So I work a patch against the trunk, including modification of fileio_write(), bufferedwriter_write() and test_fileio.py.

----------
Added file: http://bugs.python.org/file17436/issue_8765.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Sat May 22 12:11:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 22 May 2010 10:11:29 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1274523089.36.0.922670045114.issue8540@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
in sync, it would be nice to agree how they should be created.


Suggestions:

1) c = Decimal64Context

2) c = Context(Decimal64)

3) ?


I have a preference for 2). It's clear that you get a new Object and
the user does not have to wonder if a template context will be
contaminated when using setcontext(Decimal64Context).

(I know there are measures against that, but setcontext( Context(Decimal64))
is explicit rather than implicit.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Sat May 22 12:14:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 10:14:51 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1274523291.27.0.161322342959.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch:

 - make hash(m/P) preserve sign, as discussed earlier
 - add details for computing the hash of a complex number
 - reorganize sys.hash_info
    - drop sys.hash_info.bits (the exponent of the Mersenne prime);
      it's not needed in the Python code, and it can be deduced from
      the prime itself if necessary.  This also means that there's no
      public requirement that the prime be a Mersenne prime.
    - drop sys.hash_info.ninf;  just use -sys.hash_info.inf instead

    - add sys.hash_info.width:  the underlying width in bits for hashes
      of all descriptions;  in other words, it's just the number of bits
      in a C long in the current implementation
    - add sys.hash_info.imag, the multiplier used for the imaginary
      part of a complex number

----------
Added file: http://bugs.python.org/file17437/numeric_hash8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sat May 22 12:18:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 10:18:15 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1274523495.24.0.10799095221.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> 1) c = Decimal64Context
> 
> 2) c = Context(Decimal64)

Rather that complicating the Context constructor, I'd prefer a separate factory function.  I was thinking of something like:

def IEEEContext(n):
    """Return the decimal<n> IEEE 754 context.  n should be a multiple
    of 32."""
    ...

Again, it's clear with this that you get a new context object (I agree that there are problems with (1) and the mutability of Contexts).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Sat May 22 12:25:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 10:25:31 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1274523931.95.0.306238440828.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, let's open another issue for support of the IEEE 754 contexts, and keep this one for exposing _clamp.  Otherwise life gets confusing when you're trying to decide when an issue can be closed, etc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Sat May 22 12:28:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 10:28:33 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Discussion migrated from issue 8540 into its own issue.

For ease of communication with other libraries, it would be good to be able to easily create contexts corresponding to the IEEE 754 (2008) decimal interchange formats.

----------
messages: 106294
nosy: facundobatista, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: Add support for IEEE 754 contexts to decimal module.
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Sat May 22 13:22:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 May 2010 11:22:23 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274527343.24.0.730376674015.issue8765@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Amaury, do you remember if we made this deliberately?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Sat May 22 13:24:04 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 22 May 2010 11:24:04 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1274527444.86.0.497273010341.issue8786@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Some context from issue 8540:

[Stefan Krah]
> I'm busy implementing the IEEE754 contexts for cdecimal. To keep things
> in sync, it would be nice to agree how they should be created.
>
>
> Suggestions:
>
> 1) c = Decimal64Context
>
> 2) c = Context(Decimal64)


[Mark Dickinson]
> Rather that complicating the Context constructor, I'd prefer a separate factory
> function.  I was thinking of something like:
>
> def IEEEContext(n):
>     """Return the decimal<n> IEEE 754 context.  n should be a multiple
>        of 32."""
>     ...
>
> Again, it's clear with this that you get a new context object (I agree that 
> there are problems with (1) and the mutability of Contexts).

I like that, too. Where do you find the "multiple of 32" in the standard?
In a draft of IEEE 754, I only see:

Table 2?Interchange format parameters defining floating-point numbers:

  storage format: decimal32

  basic format: decimal64 and decimal128


This is what Java and decNumber offer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Sat May 22 13:29:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 11:29:41 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1274527781.87.0.664952501186.issue8786@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's Table 3.6 ("Decimal interchange format parameters") in the final version of IEEE 754;  I'm not sure what that corresponds to in the various drafts.  It has column headings: "decimal32", "decimal64", "decimal128" and "decimal{k} (k >= 32)".

Parameters for decimal{k}:  k must be a multiple of 32.  precision is   9*k/32-2.  emax is 3*2**(k/16+3).  I think these formulas all work for the specific cases k in {32, 64, 128} too, so it should be easy to check that they make sense.

They give an example below the table, too:

"For example, decimal256 would have p = 70 and emax = 1572864."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Sat May 22 13:33:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 May 2010 11:33:39 +0000
Subject: [issue3924] cookielib chokes on non-integer cookie version,
	should ignore it instead
In-Reply-To: <1222021824.75.0.209543556591.issue3924@psf.upfronthosting.co.za>
Message-ID: <1274528019.35.0.678524724754.issue3924@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch!  Applied in r81465 f.  Merged to 2.x in r81467, will merge to 3k later.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3924>
_______________________________________

From report at bugs.python.org  Sat May 22 13:34:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 May 2010 11:34:53 +0000
Subject: [issue8016] Support for cp858
In-Reply-To: <1267057078.57.0.378294218982.issue8016@psf.upfronthosting.co.za>
Message-ID: <1274528093.08.0.382969609248.issue8016@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Benjamin: OK to put this in 2.7?

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, georg.brandl
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8016>
_______________________________________

From report at bugs.python.org  Sat May 22 13:38:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 11:38:00 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1274528280.62.0.749715804149.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for changing '_clamp' into 'clamp'.

----------
keywords: +patch
Added file: http://bugs.python.org/file17438/decimal_public_clamp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Sat May 22 13:43:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 May 2010 11:43:38 +0000
Subject: [issue8635] enumerate() docstring doesn't cover optional start
	argument
In-Reply-To: <1273151764.64.0.669433681589.issue8635@psf.upfronthosting.co.za>
Message-ID: <1274528618.67.0.278697247089.issue8635@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r81468 with a slightly different patch.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8635>
_______________________________________

From report at bugs.python.org  Sat May 22 14:02:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 12:02:55 +0000
Subject: [issue8749] Cruft in object.c: PyObject_GenericGetAttr
In-Reply-To: <1274184389.99.0.605763299992.issue8749@psf.upfronthosting.co.za>
Message-ID: <1274529775.86.0.24723336992.issue8749@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r81470.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8749>
_______________________________________

From report at bugs.python.org  Sat May 22 14:07:55 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 22 May 2010 12:07:55 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274527781.87.0.664952501186.issue8786@psf.upfronthosting.co.za>
Message-ID: <20100522120520.GA18385@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark Dickinson <report at bugs.python.org> wrote:
> It's Table 3.6 ("Decimal interchange format parameters") in the final version of IEEE 754;

Thanks! I think this is not in the draft I have.

+1 for IEEEContext(n). Could we have module constants Decimal32, Decimal64 and
Decimal128 so that people coming from Java or DecNumber can write:

c = IEEEContext(Decimal64)

It is somewhat redundant, but 99% of people will use only those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Sat May 22 14:09:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 12:09:12 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1274530152.42.0.333109826508.issue8786@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Library (Lib)
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Sat May 22 14:40:23 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 22 May 2010 12:40:23 +0000
Subject: [issue8782] inspect.getsource returns invalid source for
	non-newline-ending module
In-Reply-To: <AANLkTilSLoC505RHQ1ixJRHk7mLQNMxCAC8dj2xEA1aU@mail.gmail.com>
Message-ID: <AANLkTikyEJfyRl5rf1xnV0yXyrQrPYuoMVkJLwSbyGhV@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/5/22 holger krekel <report at bugs.python.org>:
>
> holger krekel <holger.krekel at gmail.com> added the comment:
>
> Great. Also to be backported to 2.x?

That is 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8782>
_______________________________________

From report at bugs.python.org  Sat May 22 14:56:17 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 22 May 2010 12:56:17 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1274532977.76.0.109532658948.issue8540@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The patch looks good, +1 for applying it. I'm not a native speaker, but
probably:

"are subject to clamping this manner" => "are subject to clamping in this manner"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Sat May 22 16:00:32 2010
From: report at bugs.python.org (Sebastian)
Date: Sat, 22 May 2010 14:00:32 +0000
Subject: [issue8787] PySys_Get
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>


New submission from Sebastian <python.10.webmaster at spamgourmet.com>:

Hi all,

I found a bug in the exception handler. When I
start the app without any arguments I get an
output I expect:

__main__:2:DeprecationWarning: Deprecated function.

When I run the app with arguments, the arguments
are printed somehow in the exception output:

-test=HALLO:1:DeprecationWarning: Deprecated function

Can anyone please confirm?

Bye, Seb



[code]
#include "Python/Python.h"

static PyObject *testfunc(PyObject *self, PyObject *args, PyObject *keywords)
{
	PyErr_Warn(PyExc_DeprecationWarning, "Deprecated function.");
	Py_RETURN_NONE;
}

static PyMethodDef testmod[] =
{		
	{"testfunc", (PyCFunction)testfunc, METH_NOARGS, "Prints out a text to stdout."},
	{NULL}
};

int main (int argc, char **argv)
{
	Py_Initialize();
	
	PySys_SetArgv(argc, argv);
	
	PyObject *mod = Py_InitModule4("testmod", testmod, "", NULL, PYTHON_API_VERSION);
	if(mod == NULL) return -1;
	
	PyRun_SimpleString(	"import testmod\n"
											"testmod.testfunc()");
	Py_Finalize();
	return 0;
}
[/code]

----------
components: None
messages: 106306
nosy: Sebastian
priority: normal
severity: normal
status: open
title: PySys_Get
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Sat May 22 16:02:49 2010
From: report at bugs.python.org (Sebastian)
Date: Sat, 22 May 2010 14:02:49 +0000
Subject: [issue8787] PySys_Get
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1274536969.04.0.167011344378.issue8787@psf.upfronthosting.co.za>


Sebastian <python.10.webmaster at spamgourmet.com> added the comment:

Could anyone please correct the title? Thx :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Sat May 22 17:24:34 2010
From: report at bugs.python.org (Tiberius Teng)
Date: Sat, 22 May 2010 15:24:34 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1274541874.47.0.310699683341.issue6900@psf.upfronthosting.co.za>


Tiberius Teng <tiberius.teng at gmail.com> added the comment:

I believe I have isolated the problem.

After generating html help files with sphinx
$ sphinx-build -bhtmlhelp -a . build

Edit build/python265.hhp and remove following two lines:

Binary TOC=Yes
Binary Index=No

And build the chm again, the result file will have the correct 'Locate' button functionality. I believe the problem is caused by Binary TOC.

----------
nosy: +Tiberius.Teng

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Sat May 22 17:26:34 2010
From: report at bugs.python.org (Tiberius Teng)
Date: Sat, 22 May 2010 15:26:34 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1274541994.79.0.74648568539.issue6900@psf.upfronthosting.co.za>


Tiberius Teng <tiberius.teng at gmail.com> added the comment:

I have built a copy myself, with some icon style/CSS tweaking. Please test it out ;)

----------
Added file: http://bugs.python.org/file17439/python265.chm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Sat May 22 17:28:40 2010
From: report at bugs.python.org (Tiberius Teng)
Date: Sat, 22 May 2010 15:28:40 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1274542120.14.0.406723138781.issue6900@psf.upfronthosting.co.za>


Tiberius Teng <tiberius.teng at gmail.com> added the comment:

Here's the .hhp file I used to compile this chm, other files can be obtained by using HTML Help Workshop to decompile this chm.

----------
Added file: http://bugs.python.org/file17440/python265.hhp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Sat May 22 17:43:03 2010
From: report at bugs.python.org (Jeroen Habraken)
Date: Sat, 22 May 2010 15:43:03 +0000
Subject: [issue8788] urllib.urlencode documentation unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>


New submission from Jeroen Habraken <vexocide at gmail.com>:

The urllib.urlencode documentation is unclear with regard to the 'doseq' option. In my opinion it does not clearly state what its functionality is.

----------
assignee: docs at python
components: Documentation
messages: 106311
nosy: VeXocide, docs at python
priority: normal
severity: normal
status: open
title: urllib.urlencode documentation unclear on doseq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8788>
_______________________________________

From report at bugs.python.org  Sat May 22 17:50:22 2010
From: report at bugs.python.org (Jeroen Habraken)
Date: Sat, 22 May 2010 15:50:22 +0000
Subject: [issue8788] urllib.urlencode documentation unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1274543422.75.0.68264476492.issue8788@psf.upfronthosting.co.za>


Jeroen Habraken <vexocide at gmail.com> added the comment:

An elaboration as requested on IRC: It appears to make claims about 'the sequence', but doesn't make clear that 'doseq' matters when *v* is a sequence. It is easy to assume it refers to the query sequence, which is of course always a sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8788>
_______________________________________

From report at bugs.python.org  Sat May 22 18:28:08 2010
From: report at bugs.python.org (Tim Hatch)
Date: Sat, 22 May 2010 16:28:08 +0000
Subject: [issue8016] Support for cp858
In-Reply-To: <1267057078.57.0.378294218982.issue8016@psf.upfronthosting.co.za>
Message-ID: <1274545688.18.0.229300069245.issue8016@psf.upfronthosting.co.za>


Tim Hatch <tim at timhatch.com> added the comment:

I also noticed that libforensics supplies a codec for cp858, if that's helpful to double-check the implementation. http://code.google.com/p/libforensics/source/browse/code/lf/win/codepage/cp858.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8016>
_______________________________________

From report at bugs.python.org  Sat May 22 18:31:05 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 22 May 2010 16:31:05 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1274545865.17.0.621027752578.issue4769@psf.upfronthosting.co.za>


Dan Buch <daniel.buch at gmail.com> added the comment:

@haypo - what patch? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Sat May 22 19:03:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 17:03:05 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1274547785.2.0.728699920201.issue4769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This one!

----------
keywords: +patch
Added file: http://bugs.python.org/file17441/base64_main.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Sat May 22 19:05:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 May 2010 17:05:52 +0000
Subject: [issue6268] Seeking to the beginning of a text file a second time
	will return the BOM as first character
In-Reply-To: <1244744803.37.0.794266933913.issue6268@psf.upfronthosting.co.za>
Message-ID: <1274547952.04.0.244202241167.issue6268@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Fixed: 2.7 (r81459), 2.6 (r81460), 3.2 (r81461), 3.1 (r81462).

This fix doesn't work on Windows nor Solaris: it uses "wt+" file mode, whereas "t" in invalid on these OS  (does "t" mode really exist?).

While fixing this bug, I noticed two other bugs (in StreamWriter). All bugs should be fixed by a new commit: 2.7 (r81471+r81472), 2.6 (r81473), 3.2 (r81474), 3.1 (r81475).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6268>
_______________________________________

From report at bugs.python.org  Sat May 22 19:30:59 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 22 May 2010 17:30:59 +0000
Subject: [issue8789] See "Hamster" on your Google homepage
In-Reply-To: <0016e64b04fe72c1c70487322bd7@google.com>
Message-ID: <0016e64b04fe72c1c70487322bd7@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Hamster" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 106317
nosy: renben
priority: normal
severity: normal
status: open
title: See "Hamster" on your Google homepage
Added file: http://bugs.python.org/file17442/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8789>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml&source=imag">See "Hamster" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.png" alt="screenshot">

From report at bugs.python.org  Sat May 22 19:31:01 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 22 May 2010 17:31:01 +0000
Subject: [issue8790] See "Hamster" on your Google homepage
In-Reply-To: <0016e64b1e0a8e5b070487322ba4@google.com>
Message-ID: <0016e64b1e0a8e5b070487322ba4@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Hamster" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 106318
nosy: renben
priority: normal
severity: normal
status: open
title: See "Hamster" on your Google homepage
Added file: http://bugs.python.org/file17443/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8790>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml&source=imag">See "Hamster" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.png" alt="screenshot">

From report at bugs.python.org  Sat May 22 19:31:03 2010
From: report at bugs.python.org (reynaldo)
Date: Sat, 22 May 2010 17:31:03 +0000
Subject: [issue8791] See "Hamster" on your Google homepage
In-Reply-To: <0016e64caf888b30cb0487322b7d@google.com>
Message-ID: <0016e64caf888b30cb0487322b7d@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Hamster" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 106319
nosy: renben
priority: normal
severity: normal
status: open
title: See "Hamster" on your Google homepage
Added file: http://bugs.python.org/file17444/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8791>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml&source=imag">See "Hamster" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.png" alt="screenshot">

From report at bugs.python.org  Sat May 22 20:04:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 18:04:39 +0000
Subject: [issue8789] See "Hamster" on your Google homepage
In-Reply-To: <0016e64b04fe72c1c70487322bd7@google.com>
Message-ID: <1274551479.63.0.165634424629.issue8789@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8789>
_______________________________________

From report at bugs.python.org  Sat May 22 20:04:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 18:04:56 +0000
Subject: [issue8791] See "Hamster" on your Google homepage
In-Reply-To: <0016e64caf888b30cb0487322b7d@google.com>
Message-ID: <1274551496.56.0.899397777522.issue8791@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8791>
_______________________________________

From report at bugs.python.org  Sat May 22 20:05:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 18:05:13 +0000
Subject: [issue8790] See "Hamster" on your Google homepage
In-Reply-To: <0016e64b1e0a8e5b070487322ba4@google.com>
Message-ID: <1274551513.41.0.81781446384.issue8790@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8790>
_______________________________________

From report at bugs.python.org  Sat May 22 20:36:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 18:36:32 +0000
Subject: [issue8540] Make Context._clamp public in decimal module
In-Reply-To: <1272303931.23.0.317497205721.issue8540@psf.upfronthosting.co.za>
Message-ID: <1274553392.3.0.917976380039.issue8540@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for catching the doc typo!  Actually, I didn't like that doc addition anyway, so I rewrote it.

Committed in r81476.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8540>
_______________________________________

From report at bugs.python.org  Sat May 22 20:59:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 18:59:03 +0000
Subject: [issue7355] Struct incorrectly compiles format strings
In-Reply-To: <1258623721.25.0.299543316527.issue7355@psf.upfronthosting.co.za>
Message-ID: <1274554743.46.0.582549261389.issue7355@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Doc changes merged in r81477 (release26-maint) and r81480 (release31-maint).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7355>
_______________________________________

From report at bugs.python.org  Sat May 22 21:49:16 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 May 2010 19:49:16 +0000
Subject: [issue8789] See "Hamster" on your Google homepage
Message-ID: <1274557756.33.0.359199252517.issue8789@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8789>
_______________________________________

From report at bugs.python.org  Sat May 22 21:49:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 May 2010 19:49:20 +0000
Subject: [issue8789] See "Hamster" on your Google homepage
Message-ID: <1274557760.54.0.10537892635.issue8789@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file17442/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8789>
_______________________________________

From report at bugs.python.org  Sat May 22 21:49:43 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 May 2010 19:49:43 +0000
Subject: [issue8790] See "Hamster" on your Google homepage
Message-ID: <1274557783.25.0.701657679194.issue8790@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8790>
_______________________________________

From report at bugs.python.org  Sat May 22 21:49:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 May 2010 19:49:46 +0000
Subject: [issue8790] See "Hamster" on your Google homepage
Message-ID: <1274557786.19.0.132180378577.issue8790@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file17443/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8790>
_______________________________________

From report at bugs.python.org  Sat May 22 21:49:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 May 2010 19:49:58 +0000
Subject: [issue8791] See "Hamster" on your Google homepage
Message-ID: <1274557798.75.0.118754510479.issue8791@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8791>
_______________________________________

From report at bugs.python.org  Sat May 22 21:50:01 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 May 2010 19:50:01 +0000
Subject: [issue8791] See "Hamster" on your Google homepage
Message-ID: <1274557801.34.0.688820253138.issue8791@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file17444/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8791>
_______________________________________

From report at bugs.python.org  Sat May 22 21:55:15 2010
From: report at bugs.python.org (Attila Nagy)
Date: Sat, 22 May 2010 19:55:15 +0000
Subject: [issue8792] xmlrpclib compatibility issues with Apache XML-RPC library
In-Reply-To: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>
Message-ID: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>


New submission from Attila Nagy <bra at fsn.hu>:

When talking to an Apache XML-RPC library based application via python 2.6.5 xmlrpclib, I get this exception:
Traceback (most recent call last):
  File "prb.py", line 4, in <module>
    proxy.catv.getEndpointIdByIp('1.1.1.1')
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1491, in __request
    verbose=self.__verbose
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 1389, in _parse_response
    p.feed(response)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 601, in feed
    self._parser.Parse(data, 0)
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 868, in end
    return f(self, join(self._data, ""))
  File "/tmp/Python-2.6.5/Lib/xmlrpclib.py", line 935, in end_struct
    dict[_stringify(items[i])] = items[i+1]
IndexError: list index out of range

The exception is caused by the XML response, which includes a value with "ex:i8" type. According to this: http://ws.apache.org/xmlrpc/types.html, there are a lot more types, which are not understood by python's xmlrpclib.

It's easy to fix the above by adding "ex:i8" to the list of end_int dispatcher:
    def end_int(self, data):
        self.append(int(data))
        self._value = 0
    dispatch["i4"] = end_int
    dispatch["i8"] = end_int
    dispatch["ex:i8"] = end_int
    dispatch["int"] = end_int

This makes the error disappear (and the program to work).
Of course, it would be nice to support all other types as well (in both directions).

----------
components: XML
messages: 106322
nosy: bra
priority: normal
severity: normal
status: open
title: xmlrpclib compatibility issues with Apache XML-RPC library
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8792>
_______________________________________

From report at bugs.python.org  Sat May 22 22:17:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 May 2010 20:17:18 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274559438.27.0.0300208370643.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch probably needs refreshing now that first SSL contexts are in.

I wonder whether a combined boolean/string flag is really the best solution.

I think we could instead enable SNI by default and add an optional "server_hostname" to set the hostname to SSLContext.wrap_socket(), so that people can explicitly set the hostname; and otherwise take it, if possible, from the argument given to connect().

We can also add an "enable_sni" attribute to SSLContext (True by default) to allow selective disabling. This attribute would raise an exception if SNI support isn't available, which would be a way to test for it.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sun May 23 00:17:48 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 22 May 2010 22:17:48 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274566668.38.0.500008928076.issue5639@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Here's another possible approach:

ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.set_tlsext_host_name("foo.bar")
skt = ctx.wrap_socket(socket.socket())
skt.connect("bar.baz")

This makes it obvious what the SNI hostname is and what the TCP address to connect to is, and they can easily be different.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sun May 23 00:21:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 22 May 2010 22:21:40 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1274566900.65.0.949378119349.issue8786@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thinking ahead a bit:  at some point we might well also want functions to pack and unpack these IEEE formats into byte sequences, using the bit representations described in the standard.

A natural place for those functions would be as methods on a Context object;  perhaps IEEEContext should be a subclass of Context?  (OTOH, the struct module is another possible place for such functionality.)

I'll think about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Sun May 23 01:02:48 2010
From: report at bugs.python.org (Tom Seddon)
Date: Sat, 22 May 2010 23:02:48 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1274569368.03.0.618601029361.issue6900@psf.upfronthosting.co.za>


Tom Seddon <bugs.python.org at tomseddon.plus.com> added the comment:

Yes, this new version looks to do the job!

(Regarding the CSS, I'm not so sure about the serifs yet, but I'll let it sink in and see how I feel :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Sun May 23 09:07:53 2010
From: report at bugs.python.org (Daniel Black)
Date: Sun, 23 May 2010 07:07:53 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274598473.66.0.121630816864.issue5639@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

> msg106323 - Author: Antoine Pitrou (pitrou) Date: 2010-05-22 20:17

I quite like your proposed alternative here. Not sure when/if I'll get to implement this.

> msg106324  - Author: Jean-Paul Calderone (exarkun) Date: 2010-05-22 22:17
Sorry I don't like this as much. I believe following the RFC for TLS SNI should be implicit and not something the programmer need to put effort into achieving. I acknowledge this approach does go against some explicit behaviour programming quality metrics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sun May 23 11:42:00 2010
From: report at bugs.python.org (royf)
Date: Sun, 23 May 2010 09:42:00 +0000
Subject: [issue8793] IDLE crashes on opening invalid file
In-Reply-To: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>
Message-ID: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>


New submission from royf <roy.d.fox at gmail.com>:

1. Create a file containing this line:
'\xdk'

2. Open the file for editing in IDLE 2.6.4. Banner:
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

3. Run Module (F5) -> Bug#1: no error is shown

4. Run Module 7 more times (exactly!) -> Bug#2: IDLE crashes

----------
components: IDLE
messages: 106328
nosy: royf
priority: normal
severity: normal
status: open
title: IDLE crashes on opening invalid file
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8793>
_______________________________________

From report at bugs.python.org  Sun May 23 12:13:15 2010
From: report at bugs.python.org (reynaldo)
Date: Sun, 23 May 2010 10:13:15 +0000
Subject: [issue8794] Python, reynaldo bendijo wants to chat
In-Reply-To: <AANLkTin1qYGaiqdB6aGrPtCK59MYdDVGuiUGst_E--Nw@mail.gmail.com>
Message-ID: <AANLkTin1qYGaiqdB6aGrPtCK59MYdDVGuiUGst_E--Nw@mail.gmail.com>


New submission from reynaldo <renben77 at gmail.com>:

I've been using Google Talk and thought you might like to try it out.
We can use it to call each other for free over the internet. Here's an
invitation to download Google Talk. Give it a try!

-----------------------------------------------------------------------

reynaldo bendijo wants to stay in better touch using some of Google's
coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-bea89ac769-8aa0f7d30c-M7u-8vnkjuK6niiM4o2sjhHHJRw
You'll need to click this link to be able to chat with reynaldo bendijo.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with reynaldo bendijo, visit:
http://mail.google.com/mail/a-bea89ac769-8aa0f7d30c-M7u-8vnkjuK6niiM4o2sjhHHJRw

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
  client

We're working hard to add new features and make improvements, so we might also
ask for your comments and suggestions periodically. We appreciate your help in
making our products even better!

Thanks,
The Google Team

To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).

----------
messages: 106329
nosy: renben
priority: normal
severity: normal
status: open
title: Python, reynaldo bendijo wants to chat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8794>
_______________________________________

From report at bugs.python.org  Sun May 23 12:17:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 May 2010 10:17:24 +0000
Subject: [issue8794] spam
In-Reply-To: <AANLkTin1qYGaiqdB6aGrPtCK59MYdDVGuiUGst_E--Nw@mail.gmail.com>
Message-ID: <1274609844.29.0.65981214695.issue8794@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed
title: Python, reynaldo bendijo wants to chat -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8794>
_______________________________________

From report at bugs.python.org  Sun May 23 12:17:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 May 2010 10:17:37 +0000
Subject: [issue8794] spam
Message-ID: <1274609857.58.0.830228528187.issue8794@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8794>
_______________________________________

From report at bugs.python.org  Sun May 23 12:18:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 May 2010 10:18:35 +0000
Subject: [issue8791] spam
Message-ID: <1274609915.5.0.189261184.issue8791@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: See "Hamster" on your Google homepage -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8791>
_______________________________________

From report at bugs.python.org  Sun May 23 12:18:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 May 2010 10:18:51 +0000
Subject: [issue8790] spam
Message-ID: <1274609931.57.0.544717156148.issue8790@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: See "Hamster" on your Google homepage -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8790>
_______________________________________

From report at bugs.python.org  Sun May 23 12:19:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 May 2010 10:19:09 +0000
Subject: [issue8789] spam
Message-ID: <1274609949.42.0.463332471214.issue8789@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
title: See "Hamster" on your Google homepage -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8789>
_______________________________________

From report at bugs.python.org  Sun May 23 13:26:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 23 May 2010 11:26:14 +0000
Subject: [issue1368368] prompt_user_passwd() in FancyURLopener masks 401
	Unauthorized error page
Message-ID: <1274613974.94.0.553327995392.issue1368368@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368368>
_______________________________________

From report at bugs.python.org  Sun May 23 13:28:44 2010
From: report at bugs.python.org (Arie Skliarouk)
Date: Sun, 23 May 2010 11:28:44 +0000
Subject: [issue8795] Error sending utf8 strings over syslog udp protocol
In-Reply-To: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>
Message-ID: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>


New submission from Arie Skliarouk <skliarie at gmail.com>:

I am trying to send utf8 strings over syslog/udp and get strange error:
Traceback (most recent call last):
  File "/usr/lib/python2.6/logging/handlers.py", line 788, in emit
    self.socket.sendto(msg, self.address)
TypeError: sendto() takes exactly 3 arguments (2 given)

See the attached program, at the beginning it has two parameters - log to file or udp and use utf8 or not. It works in all cases but the udp+utf8.

----------
components: Unicode
files: logger_udp_utf8.py
messages: 106330
nosy: skliarie
priority: normal
severity: normal
status: open
title: Error sending utf8 strings over syslog udp protocol
versions: Python 2.6
Added file: http://bugs.python.org/file17445/logger_udp_utf8.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8795>
_______________________________________

From report at bugs.python.org  Sun May 23 13:44:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 May 2010 11:44:53 +0000
Subject: [issue8795] Error sending utf8 strings over syslog udp protocol
In-Reply-To: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>
Message-ID: <1274615093.59.0.459293546595.issue8795@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8795>
_______________________________________

From report at bugs.python.org  Sun May 23 13:53:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 May 2010 11:53:41 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274615621.77.0.32793557213.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
> ctx.set_tlsext_host_name("foo.bar")

Well, the hostname should be specific to a connection, so I'm not sure it makes sense to set it on the context.
(besides, the OpenSSL APIs only allow it to be set on the SSL structure)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sun May 23 13:56:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 May 2010 11:56:52 +0000
Subject: [issue8792] xmlrpclib compatibility issues with Apache XML-RPC library
In-Reply-To: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>
Message-ID: <1274615812.76.0.542361158661.issue8792@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8792>
_______________________________________

From report at bugs.python.org  Sun May 23 14:48:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 May 2010 12:48:43 +0000
Subject: [issue6900] Sub-optimal "Locate" button behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1274618923.72.0.0233934356013.issue6900@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I've now deactivated the "Binary TOC" setting in Sphinx' repo; it will be used for Python when I release a new version.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________

From report at bugs.python.org  Sun May 23 15:35:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 May 2010 13:35:22 +0000
Subject: [issue8188] Unified hash for numeric types.
In-Reply-To: <1269117270.13.0.417099891076.issue8188@psf.upfronthosting.co.za>
Message-ID: <1274621722.61.0.908162712033.issue8188@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed the hash changes in r81486.  This commit just changes the method for computing hash values;  it doesn't include the changes to the decimal module that make Decimal instances comparable with Fraction instances.

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8188>
_______________________________________

From report at bugs.python.org  Sun May 23 17:22:31 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 23 May 2010 15:22:31 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1274628151.22.0.223845346519.issue1628205@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

Backported to release26-maint in r81488.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Sun May 23 17:34:57 2010
From: report at bugs.python.org (vila)
Date: Sun, 23 May 2010 15:34:57 +0000
Subject: [issue8354] siginterrupt with flag=False is reset when signal received
In-Reply-To: <1270795837.87.0.683673992087.issue8354@psf.upfronthosting.co.za>
Message-ID: <1274628897.24.0.738248854815.issue8354@psf.upfronthosting.co.za>


Changes by vila <v.ladeuil+bugs-python at free.fr>:


----------
nosy: +vila

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8354>
_______________________________________

From report at bugs.python.org  Sun May 23 17:35:30 2010
From: report at bugs.python.org (vila)
Date: Sun, 23 May 2010 15:35:30 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1274628930.32.0.353663928201.issue1628205@psf.upfronthosting.co.za>


Changes by vila <v.ladeuil+bugs-python at free.fr>:


----------
nosy: +vila

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Sun May 23 18:37:50 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 23 May 2010 16:37:50 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274632670.7.0.78064780398.issue5639@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> Sorry I don't like this as much. I believe following the RFC for TLS SNI should be implicit and not something the programmer need to put effort into achieving. I acknowledge this approach does go against some explicit behaviour programming quality metrics.

It's almost always wrong for Python to enforce a particular *policy*, particularly in a very low level API (which is what the ssl module should be).  Python's main job is to make it *possible* to do things.  It's the application developer's job to decide what things should be done.

It would be entirely appropriate, though, for a higher-level interface (for example, the httplib module) to take care of this itself and not require users to explicitly specify things separately.

> Well, the hostname should be specific to a connection, so I'm not sure it makes sense to set it on the context.

That doesn't make sense to me.  For example, consider the case where you're talking to a web service.  The hostname lookup might result in 10 A records, which you then drop into a connection pool.  Your application doesn't care which server you talk to (and maybe it talks to serveral, or all, of them).  But it does want to specify the same hostname for each.

> (besides, the OpenSSL APIs only allow it to be set on the SSL structure)

Nope, I checked before making the suggestion.  There's an SSL_CTX_ version of this API (in addition to the SSL_ version).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sun May 23 18:42:43 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 23 May 2010 16:42:43 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274632963.19.0.21113965136.issue5639@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> Nope, I checked before making the suggestion.  There's an SSL_CTX_ version of this API (in addition to the SSL_ version).

Sorry, I just checked again, and it seems you're right.  Perhaps I saw SSL_CTX_set_tlsext_servername_callback and got the two confused.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Sun May 23 19:14:58 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 23 May 2010 17:14:58 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274634898.72.0.245000279233.issue8611@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I'm skeptical about surrogates particularly for that problem.
>From my perspective the solution is only to use native unicode support for windows file operation functions.
Conversions utf-8 -> mbcs -> utf8 will loose encoding information thanks to tricky Microsoft mbcs encoding schema.
If I'm wrong please correct me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sun May 23 19:16:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 23 May 2010 17:16:25 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274634985.76.0.908348541591.issue1436346@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching a documentation patch.

----------
Added file: http://bugs.python.org/file17446/issue1436346-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Sun May 23 19:18:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 23 May 2010 17:18:00 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274635080.63.0.350929046972.issue1436346@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: belopolsky -> 
components: +Documentation
keywords: +needs review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Sun May 23 19:53:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 May 2010 17:53:36 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1274637216.43.0.177126261902.issue7983@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Sun May 23 21:27:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 May 2010 19:27:55 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

codecs module (and codecs.open() function) was added to Python 2.0. codecs.open() creates a StreamReaderWriter object which use two other objects: StreamReader and StreamWriter.

Python 2.6 and 3.0 have a new API: the io module. io.open() creates a TextIOWrapper object which is fully compatible with the file object API (it *is* the (text) file object API :-)). TextIOWrapper supports univeral newline and does better support reading+writing than StreamReaderWriter. TextIOWrapper has a better test suite and is used by default to read and write text files in Python3 (since Python 3.0). The io module has an *optimized* design and the io module was rewritten in C (in Python 2.7 and 3.1).

codecs.open() should be deprecated in Python 3.2 and removed in Python 3.3 (not in Python 2.7). Maybe also StreamReader, StreamWriter and StreamReaderWriter: I don't know if any program use directly these classes, but I think that TextIOWrapper can be used instead.

----------
components: Library (Lib), Unicode
messages: 106339
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Deprecate codecs.open()
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Sun May 23 21:40:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 May 2010 19:40:31 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274643631.62.0.141328361314.issue8796@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Sun May 23 21:41:52 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 23 May 2010 19:41:52 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1274643712.42.0.42249043831.issue8446@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Not sure I understand this patch.  Either the icglue module is removed in python 3, in which case it should raise the deprecation warning, or it is not, in which case it should be removed from the list of modules checked in test_py3kwarn.  Shouldn't the patch also address one of these two cases?

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Sun May 23 23:55:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 23 May 2010 21:55:57 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1274651757.06.0.933303007641.issue1436346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r81489.  Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Mon May 24 06:49:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 May 2010 04:49:54 +0000
Subject: [issue8750] Many of MutableSet's methods assume that the other
	parameter is not self
In-Reply-To: <1274190262.36.0.827917272731.issue8750@psf.upfronthosting.co.za>
Message-ID: <1274676594.53.0.477162334766.issue8750@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8750>
_______________________________________

From report at bugs.python.org  Mon May 24 07:26:14 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 24 May 2010 05:26:14 +0000
Subject: [issue1368368] prompt_user_passwd() in FancyURLopener masks 401
	Unauthorized error page
Message-ID: <1274678774.57.0.45897968813.issue1368368@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Since urllib.urlopen() is removed in py3k, and is intended to be replaced by urllib2.urlopen(), I think we'd better just leave as it is.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368368>
_______________________________________

From report at bugs.python.org  Mon May 24 08:33:50 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 24 May 2010 06:33:50 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1274682830.24.0.0480527696695.issue8446@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patch somewhat works, in that it makes test_py3kwarn pass but I'd add more filterwarning calls:

        filterwarnings("ignore", ".*the icglue module is removed",
            DeprecationWarning)
        filterwarnings("ignore", ".*the MacOS module is removed",
            DeprecationWarning)
        filterwarnings("ignore", ".*the macostools module is removed",
            DeprecationWarning)

This ensures that importing webbrowser won't trigger py3k warnings.
 
It is probably safe to remove the import of 'ic' and related code the block with guard "if sys.platform == 'darwin'" just below that overrides the IC based browser detection by one that doesn't use IC (that one is added to the front of the search list, which means the IC one never gets used).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Mon May 24 09:34:42 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 May 2010 07:34:42 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1274686482.99.0.0369225763011.issue8797@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Is the behavior you posted observable on trunk?

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8797>
_______________________________________

From report at bugs.python.org  Mon May 24 09:36:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 May 2010 07:36:52 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1274686612.56.0.757211687014.issue8797@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Okay, I see you have mentioned 2.6.5 in the Title.
I will try the following to reproduce this.
1) Try a Basis Auth which is working.
2) Pass an Invalid username/password and see the behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8797>
_______________________________________

From report at bugs.python.org  Mon May 24 11:06:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 24 May 2010 09:06:47 +0000
Subject: [issue8798] tkinter build variants on OSX
In-Reply-To: <1274692007.27.0.519809230611.issue8798@psf.upfronthosting.co.za>
Message-ID: <1274692007.27.0.519809230611.issue8798@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

It would be nice if the binary installer supported both Tk 8.4 and Tk 8.5: the former is present on all current versions of OSX as part of the system, the latter is the only one that is supported in 64-bit code on OSX  10.6.

A number of Tkinter users have also mentioned that they would much prefer to target Tk 8.5 due to a large number of bugfixes in that version (on OSX).

What I'm thinking of is:

have _tkinter.py that does:

try:
   from _tkinter85 import *
except ImportError:
   from _tkinter84 import *

Then patch setup.py to build _tkinter84.so and _tkinter85.so from _tkinter.c while linking to the right version of Tk. This should only be done when a special configure argument is present, if it isn't setup.py should default to building _tkinter.so like it currently does. 

I don't have time to work on a patch myself.

Workaround for this request: build your own copy of _tkinter when you want to use Tk 8.5 (or later) and use sys.path manipulation to ensure that that copy is used.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 106347
nosy: ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: tkinter build variants on OSX
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8798>
_______________________________________

From report at bugs.python.org  Mon May 24 11:07:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 24 May 2010 09:07:00 +0000
Subject: [issue8798] tkinter build variants on OSX
In-Reply-To: <1274692007.27.0.519809230611.issue8798@psf.upfronthosting.co.za>
Message-ID: <1274692020.54.0.50766667093.issue8798@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee: ronaldoussoren -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8798>
_______________________________________

From report at bugs.python.org  Mon May 24 11:43:59 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 May 2010 09:43:59 +0000
Subject: [issue8795] Error sending utf8 strings over syslog udp protocol
In-Reply-To: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>
Message-ID: <1274694239.89.0.868875148473.issue8795@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The message is a misleading one which seems to happen because a Unicode object is passed to the socket.

This was fixed in trunk in r75586 (21 October 2009). I've now backported it to release26-maint (r81494).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8795>
_______________________________________

From report at bugs.python.org  Mon May 24 11:44:18 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 May 2010 09:44:18 +0000
Subject: [issue8799] Hang in lib/test/test_threading.py
In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>
Message-ID: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The tests for the ConditionVariable a fragile.  On a slow computer, or when running a DEBUG build, the main thread can issue a condition.notify() call, even though the worker threads have not settled in on a wait() call.  This causes the test to stall.
The provided patch "fixes" this by adding a short _wait() before the notify.

----------
components: Library (Lib)
files: locktest.patch
keywords: easy, patch, patch
messages: 106349
nosy: krisvale
priority: normal
severity: normal
status: open
title: Hang in lib/test/test_threading.py
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17447/locktest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8799>
_______________________________________

From report at bugs.python.org  Mon May 24 11:55:43 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 May 2010 09:55:43 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Provided is a patch, implementing a RWLock using a ConditionVariable and Lock.
It has rdlock() and wrlock() methods, and an unlock() method, similar to the rwlock API in pthreads.
It has context managers rdlocked() and wrlocked().
In addition, it conforms to the RLock interface, with acquire() and release() being aliases to wrlock() and unlock() respectively and when used as a context manager, it gets a wrlock()
There is no documentation yet, since this is just a proposal, but there are unit tests.

See also issue 8777 for another locking primitive, the Barrier.

----------
components: Library (Lib)
files: rwlock.patch
keywords: needs review, patch, patch
messages: 106350
nosy: krisvale
priority: normal
severity: normal
status: open
title: add threading.RWLock
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17448/rwlock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 12:23:23 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 May 2010 10:23:23 +0000
Subject: [issue8801] Inconsistency in behaviour of urllib and urllib2 with
	file:// URLs
In-Reply-To: <1274696603.9.0.49787272885.issue8801@psf.upfronthosting.co.za>
Message-ID: <1274696603.9.0.49787272885.issue8801@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

I encountered what seems like an incompatibility between urllib and urllib2 in the way they handle file:// URLs. Here's a console session to illustrate:

vinay <at> eta-karmic:/tmp$ echo Hello, world! >hello.txt
vinay <at> eta-karmic:/tmp$ cat hello.txt 
Hello, world!
vinay <at> eta-karmic:/tmp$ python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib,urllib2
>>> s = 'file:////tmp/hello.txt'
>>> f1 = urllib.urlopen(s)
>>> f1.read()
'Hello, world!\n'
>>> f2 = urllib2.urlopen(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1240, in file_open
    return self.parent.open(req)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1287, in ftp_open
    raise URLError('ftp error: no host given')
urllib2.URLError: <urlopen error ftp error: no host given>
>>> 

The problem appears to be that urllib allows a badly-formed file URL (with file://// rather than file:///) when it shouldn't (errors should not pass silently).

----------
messages: 106351
nosy: vinay.sajip
priority: low
severity: normal
status: open
title: Inconsistency in behaviour of urllib and urllib2 with file:// URLs
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8801>
_______________________________________

From report at bugs.python.org  Mon May 24 12:58:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 24 May 2010 10:58:17 +0000
Subject: [issue8801] Inconsistency in behaviour of urllib and urllib2 with
	file:// URLs
In-Reply-To: <1274696603.9.0.49787272885.issue8801@psf.upfronthosting.co.za>
Message-ID: <1274698697.34.0.39892148537.issue8801@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8801>
_______________________________________

From report at bugs.python.org  Mon May 24 13:26:37 2010
From: report at bugs.python.org (Arie Skliarouk)
Date: Mon, 24 May 2010 11:26:37 +0000
Subject: [issue8795] Error sending utf8 strings over syslog udp protocol
In-Reply-To: <1274614124.24.0.553377006251.issue8795@psf.upfronthosting.co.za>
Message-ID: <1274700397.84.0.806347486469.issue8795@psf.upfronthosting.co.za>


Arie Skliarouk <skliarie at gmail.com> added the comment:

How come the fix from October 21 have not got into Python 2.6.5 that is packaged into ubuntu 10.04?

I overwrote the handlers.py from existing python 2.6.5 installation with the patched version and verified that utf8-encoded logs pass properly now.

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8795>
_______________________________________

From report at bugs.python.org  Mon May 24 13:39:21 2010
From: report at bugs.python.org (sivaramakrishna uddanti)
Date: Mon, 24 May 2010 11:39:21 +0000
Subject: [issue8802] about oa module
In-Reply-To: <1274701161.14.0.0502226898234.issue8802@psf.upfronthosting.co.za>
Message-ID: <1274701161.14.0.0502226898234.issue8802@psf.upfronthosting.co.za>


New submission from sivaramakrishna uddanti <sivaram.uddanti at gmail.com>:

i want to know about the oa module in python .. i searched in google but it was to no avail .. please provide me with the details of the mentioned module ..

----------
components: Extension Modules
messages: 106353
nosy: sudanti
priority: normal
severity: normal
status: open
title: about oa module
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8802>
_______________________________________

From report at bugs.python.org  Mon May 24 13:41:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 11:41:07 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274701267.75.0.531213191252.issue8800@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +jyasskin
stage:  -> patch review
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 13:41:26 2010
From: report at bugs.python.org (sivaramakrishna uddanti)
Date: Mon, 24 May 2010 11:41:26 +0000
Subject: [issue8803] about oa module
In-Reply-To: <1274701286.05.0.166496398386.issue8803@psf.upfronthosting.co.za>
Message-ID: <1274701286.05.0.166496398386.issue8803@psf.upfronthosting.co.za>


New submission from sivaramakrishna uddanti <sivaram.uddanti at gmail.com>:

i want to know about the oa module in python.. i searched in the google but it was to no avail . please provide me with the details of mentioned module..

----------
components: Extension Modules
messages: 106354
nosy: sudanti
priority: normal
severity: normal
status: open
title: about oa module
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8803>
_______________________________________

From report at bugs.python.org  Mon May 24 13:43:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 11:43:22 +0000
Subject: [issue8799] Hang in lib/test/test_threading.py
In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>
Message-ID: <1274701402.59.0.214078321557.issue8799@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Strange, I have never noticed this (even on the buildbots).

----------
nosy: +jyasskin, pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8799>
_______________________________________

From report at bugs.python.org  Mon May 24 13:47:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 May 2010 11:47:13 +0000
Subject: [issue8802] about oa module
In-Reply-To: <1274701161.14.0.0502226898234.issue8802@psf.upfronthosting.co.za>
Message-ID: <1274701633.9.0.548561559299.issue8802@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This tracker is for reporting and fixing bugs in Python;  it isn't the right place for your question.  You could try asking on the comp.lang.python newsgroup (also available as a mailing list:  http://mail.python.org/pipermail/python-list/ ).

[AFAIK, no such Python module exists; at least, not as part of the standard distribution.]

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8802>
_______________________________________

From report at bugs.python.org  Mon May 24 13:48:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 May 2010 11:48:04 +0000
Subject: [issue8803] about oa module
In-Reply-To: <1274701286.05.0.166496398386.issue8803@psf.upfronthosting.co.za>
Message-ID: <1274701684.92.0.474986820047.issue8803@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Duplicate of issue 8802.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8803>
_______________________________________

From report at bugs.python.org  Mon May 24 14:01:14 2010
From: report at bugs.python.org (sivaramakrishna uddanti)
Date: Mon, 24 May 2010 12:01:14 +0000
Subject: [issue8802] about oa module
In-Reply-To: <1274701633.9.0.548561559299.issue8802@psf.upfronthosting.co.za>
Message-ID: <AANLkTikNty3Un2Azo5Wfdtj3v13GAOhJokhS2FRZ-Swh@mail.gmail.com>


sivaramakrishna uddanti <sivaram.uddanti at gmail.com> added the comment:

if it is (oa module) not existing , how are functions like oa.oaString()
,oa.oaWaferInit() working in the script i have .....

On Mon, May 24, 2010 at 5:17 PM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> This tracker is for reporting and fixing bugs in Python;  it isn't the
> right place for your question.  You could try asking on the comp.lang.python
> newsgroup (also available as a mailing list:
> http://mail.python.org/pipermail/python-list/ ).
>
> [AFAIK, no such Python module exists; at least, not as part of the standard
> distribution.]
>
> ----------
> nosy: +mark.dickinson
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8802>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file17449/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8802>
_______________________________________
-------------- next part --------------
if it is (oa module)??not existing , how??are functions like oa.oaString() ,oa.oaWaferInit() working in the script i have .....<br><br>
<div class="gmail_quote">On Mon, May 24, 2010 at 5:17 PM, Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>This tracker is for reporting and fixing bugs in Python; ??it isn&#39;t the right place for your question. ??You could try asking on the comp.lang.python newsgroup (also available as a mailing list: ??<a href="http://mail.python.org/pipermail/python-list/" target="_blank">http://mail.python.org/pipermail/python-list/</a> ).<br>
<br>[AFAIK, no such Python module exists; at least, not as part of the standard distribution.]<br><br>----------<br>nosy: +mark.dickinson<br>resolution: ??-&gt; invalid<br>status: open -&gt; closed<br>
<div>
<div></div>
<div class="h5"><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue8802" target="_blank">http://bugs.python.org/issue8802</a>&gt;<br>
_______________________________________<br></div></div></blockquote></div><br>

From report at bugs.python.org  Mon May 24 14:06:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 May 2010 12:06:19 +0000
Subject: [issue8802] about oa module
In-Reply-To: <1274701161.14.0.0502226898234.issue8802@psf.upfronthosting.co.za>
Message-ID: <1274702779.92.0.772386664896.issue8802@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To repeat:  this is the wrong forum for these questions;  please take them elsewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8802>
_______________________________________

From report at bugs.python.org  Mon May 24 14:11:47 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 May 2010 12:11:47 +0000
Subject: [issue8799] Hang in lib/test/test_threading.py
In-Reply-To: <1274694258.02.0.421667436928.issue8799@psf.upfronthosting.co.za>
Message-ID: <1274703107.1.0.242110454231.issue8799@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well, I saw this occasionally on my dual core laptop when working on the RWLock.  A notify() before a target does a wait() is ineffective and it would wait indefinitely after the notify(5) call.  This isn't a "proper" fix (I had another, more complex, where we would keep a counter for the number of successful "waiters" and wait for that to reach the target value) but it is in the spirit of many of these tests, where we rely on _wait() to be sufficient to reach a certain state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8799>
_______________________________________

From report at bugs.python.org  Mon May 24 15:02:02 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 24 May 2010 13:02:02 +0000
Subject: [issue8795] Error sending utf8 strings over syslog udp protocol
In-Reply-To: <1274700397.84.0.806347486469.issue8795@psf.upfronthosting.co.za>
Message-ID: <222827.60207.qm@web25803.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

----- Original Message ----

> From: Arie Skliarouk <report at bugs.python.org>
> How come the fix from October 21 have not got into Python 2.6.5 
> that is packaged into ubuntu 10.04?

Not all bug-fixes are automatically backported from trunk to release26-maint branch, which is where 2.6.x releases come from. If someone reports a problem, then I would certainly look to see if a backport is feasible, and this time it was :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8795>
_______________________________________

From report at bugs.python.org  Mon May 24 18:02:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:02:04 +0000
Subject: [issue8804] http.client should support SSL contexts
In-Reply-To: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>
Message-ID: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/http.client.html

http.client.HTTPSConnection should allow passing an SSL context object instead of a cert/key pair.

----------
components: Library (Lib)
messages: 106362
nosy: giampaolo.rodola, orsenthil, pitrou
priority: normal
severity: normal
status: open
title: http.client should support SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8804>
_______________________________________

From report at bugs.python.org  Mon May 24 18:04:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:04:04 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/http.client.html

urllib.request.*URLOpener should allow passing an SSL context object, if not already possible.

(I hope you don't mind the multiple similar issues, but I think one separate issue per stdlib module is more manageable)

----------
components: Library (Lib)
messages: 106363
nosy: pitrou
priority: normal
severity: normal
status: open
title: urllib should support SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8805>
_______________________________________

From report at bugs.python.org  Mon May 24 18:05:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:05:03 +0000
Subject: [issue8804] http.client should support SSL contexts
In-Reply-To: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>
Message-ID: <1274717103.85.0.367761827339.issue8804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, sorry for the bad URL:
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8804>
_______________________________________

From report at bugs.python.org  Mon May 24 18:05:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:05:14 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1274717114.96.0.519394361104.issue8805@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actual URL for SSL contexts (sorry):
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8805>
_______________________________________

From report at bugs.python.org  Mon May 24 18:05:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:05:42 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1274717142.0.0.294445571035.issue8805@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8805>
_______________________________________

From report at bugs.python.org  Mon May 24 18:07:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:07:42 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The FTP_TLS constructor should allow passing an SSL context object instead of a key/cert pair.

----------
messages: 106366
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: ftplib should support SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Mon May 24 18:10:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:10:53 +0000
Subject: [issue8807] poplib should support SSL contexts
In-Reply-To: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>
Message-ID: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The POP3_SSL constructor should allow passing an SSL context object instead of a key/cert pair.

----------
components: Library (Lib)
messages: 106367
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: poplib should support SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8807>
_______________________________________

From report at bugs.python.org  Mon May 24 18:13:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:13:57 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The IMAP4_SSL constructor should allow passing an SSL context object instead of a key/cert pair.

----------
components: Library (Lib)
messages: 106368
nosy: pitrou
priority: normal
severity: normal
status: open
title: imaplib should support SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Mon May 24 18:14:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:14:26 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1274717666.85.0.501051830026.issue8808@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Mon May 24 18:15:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:15:42 +0000
Subject: [issue8809] smptlib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.2 introduces SSL contexts, which allow bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure.
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLContext

The SMTP_SSL constructor should allow passing an SSL context object instead of a key/cert pair.

----------
components: Library (Lib)
messages: 106369
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: smptlib should support SSL contexts
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Mon May 24 18:18:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:18:49 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1274717929.58.0.263990381191.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Python's main job is to make it *possible* to do things.  It's the
> application developer's job to decide what things should be done.

> It would be entirely appropriate, though, for a higher-level interface 
> (for example, the httplib module) to take care of this itself and not 
> require users to explicitly specify things separately.

Ok, I find this argument rather convincing. Also, enabling implicit SNI with the connect() argument could make user code stop working if he decides to pass the IP instead, without him being able to diagnose precisly what happens.

As you said, httplib/urllib should probably enable client-side SNI by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Mon May 24 18:20:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 16:20:21 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>From <http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset>:

"""
tzinfo.utcoffset(self, dt)

    Return offset of local time from UTC, in minutes east of UTC. 
"""

This suggests that the return value is an integer representing the number of minutes.  It is later explained that in fact "the value returned must be a timedelta object specifying a whole number of minutes", but many users won't read past the first sentence.

I suggest s/in minutes east of UTC/as a timedelta object/.  I think "east of UTC" is redundant given the next sentence, "If local time is west of UTC, this should be negative", but that can also be reworded for clarity as "The offset for timezones west of UTC is negative, and for those east of UTC is positive."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 106371
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: TZ offset description is unclear in docs
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Mon May 24 18:39:12 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 24 May 2010 16:39:12 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274719152.87.0.271850521769.issue8800@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

This patch doesn't apply cleanly against the py3k tree. Since Python 2.7 is in beta, and there's no 2.8, this can only go into python 3, so you should work against that tree.

It's a bit annoying that the R in RWLock stands for a different word from in RLock. But I can't think of a better name.

Hm, the test for RWLock should use a Barrier to check for multiple readers.

I wonder if it makes sense to add a DeadlockError as a subclass of RuntimeError and throw that from trying to upgrade a read-lock to a write-lock.

The docs should describe why upgrading a read-lock to a write-lock is banned, or else people will try to add the feature.


test_wrrecursion should also check pure writer recursion. Oh, no, that's tested by RLockTests. Comment that please. The name of the test should probably mention write_then_read_recursion to distinguish it from write-then-write or read-then-write.

test_readers_writers doesn't quite test enough. (Feel free to add another test rather than changing this one.) You want to test that readers can't starve writers. For example, say we have:
  lock = RWLock()
  done = False
  def r():
    with lock.rdlocked():
      if done:
        return
      _wait()
  def w():
    nonlocal done
    with lock.wrlocked():
      done = True
  readers = Bunch(r, 50)
  _wait()
  writers = Bunch(w, 1)
  readers.wait_for_finished()
  writers.wait_for_finished()

In a naive implementation, there may never be a point where no reader has the lock held, and so the writer may never get in to tell them all to exit. I believe your implementation will already pass this test.

spelling: mathced

I'm not sure that "#threads will be few" is true for a read-lock, but I don't mind for the first implementation.

Generally put a space after # when it introduces a comment, start comments with a capital letter, and end them with punctuation so we know you didn't stop typing early.

In _rdlock could you flip the "not self.nw" condition? That way the else won't be a double-negative.

Can self.rcond.wait() ever throw an exception? I suspect you should use try:finally: to guard the "self.nr -= 1"

Why must the user hold a write lock to use Condition.wait? Semantically, a waiting on a read-lock would release the current thread's recursive read-locks, and all should be well.

It looks like self.owning holds one copy of each thread's id for each re-entry by that thread. That wasn't obvious so deserves a comment.

General API questions: 
 1. Given that the other locking APIs use "acquire" and "release" instead of "lock" and "unlock", perhaps this class should use "rdacquire" and "wracquire"?
 2. I wonder if it helps actual code to be able to just call "unlock" instead of "rdunlock" and "wrunlock". Code releasing the lock should always know which kind of lock it holds.

Otherwise, this looks basically correct. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 18:40:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:40:06 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274719206.88.0.303608710613.issue8800@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure it's a good idea to have a default context manager, and default acquire/release methods. "In the face of ambiguity, refuse the temptation to guess".

Is there any use in being able to use a RWLock inside a condition variable?

Docstrings should be polished (e.g. typo "must be mathced with an release"). I think wrlocked() and rdlocked() deserve a docstring too.

A style nit: generally, comments should be on their own line, before the code they comment. Also, there should be a space just after the "#" (see PEP 8 :-)).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 18:44:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 16:44:16 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274719456.9.0.257919681255.issue8777@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Mon May 24 18:46:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 16:46:35 +0000
Subject: [issue5288] tzinfo objects with sub-minute offsets are not supported
	(e.g. UTC+05:53:28)
In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
Message-ID: <1274719595.99.0.468866104457.issue5288@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As far as I can tell, the TZ offset code can be simplified by eliminating conversion from timedelta to int and back in utcoffset() and dst() methods of time and datetime objects.

The only reason for the restriction that I can think of is that some text representation of datetime only provide 4 digits for timezone. The behavior of formatting functions, can be preserved while allowing fractional minute offsets elsewhere.

On the other hand, given that this issue did not see a single response in more than a year, it seems that there is little interest in fixing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5288>
_______________________________________

From report at bugs.python.org  Mon May 24 19:31:32 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 24 May 2010 17:31:32 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274722292.85.0.285933641571.issue8777@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

You should probably mention that pthread_barrier and java.util.concurrent.CyclicBarrier are prior art for this. I'm thinking about them when looking at the API to see whether your differences make sense.

"enter" seems to be the wrong term for this, since there's no matching "exit" call. "wait" or "block" seem better.

Both pthread_barrier and CyclicBarrier provide a way to identify a unique thread from each group. pthread_barrier_wait returns true in exactly one thread, while CyclicBarrier runs a callback while all other threads are still paused. I'd be inclined to use CyclicBarrier's interface here, although then you have to define what happens when the action raises an exception.

_release should notify_all after its loop.

adjust_count makes me nervous. Is there a context manager interface that would make this cleaner/safer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Mon May 24 19:43:39 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 24 May 2010 17:43:39 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274723019.82.0.91925312787.issue8800@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

In this case, "acquire" isn't ambiguous. All the other lock types actually acquire a write lock, so it makes sense to have the operation with the same name they use also acquire a write lock on this object.

I realized that read/write locks are actually shared/exclusive locks, which might form the basis for a name that doesn't collide with RLock. Boost (http://www.boost.org/doc/libs/1_43_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_types.shared_mutex) uses shared_mutex for the concept, so SLock or SELock? There are some algorithms that write while the lock is acquired non-exclusive, so "shared" is actually a better name for the concept, even though posix and Java used read/write.

The possibility of lock downgrading (turning an exclusive lock into a shared lock, without allowing any other exclusive acquisitions in the mean time) might inform your decision about how to name "unlock".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 19:51:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 17:51:13 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274723019.82.0.91925312787.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274723468.3200.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In this case, "acquire" isn't ambiguous. All the other lock types
> actually acquire a write lock, so it makes sense to have the operation
> with the same name they use also acquire a write lock on this object.

Well, it looks like a strange kind of "consistency" to me, since other
lock types are not dual. Both posix and Java APIs don't seem to imply
that the write lock is the "default" lock in a RW lock. However, I'm not
a synchronization specialist.

> I realized that read/write locks are actually shared/exclusive locks,
> which might form the basis for a name that doesn't collide with RLock.
> Boost
> (http://www.boost.org/doc/libs/1_43_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_types.shared_mutex) uses shared_mutex for the concept, so SLock or SELock?

SELock looks ok, but I have to say that RWLock is more obvious (I don't
need to do a search to guess that RW means "read/write").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 20:16:37 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:16:37 +0000
Subject: [issue8809] smptlib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1274724997.46.0.827807356553.issue8809@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Mon May 24 20:16:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:16:50 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1274725010.25.0.402474944103.issue8808@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Mon May 24 20:17:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:17:02 +0000
Subject: [issue8807] poplib should support SSL contexts
In-Reply-To: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>
Message-ID: <1274725022.97.0.977861156155.issue8807@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8807>
_______________________________________

From report at bugs.python.org  Mon May 24 20:17:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:17:14 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274725034.09.0.082062280216.issue8806@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Mon May 24 20:17:17 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:17:17 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1274725037.15.0.196023183361.issue8805@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8805>
_______________________________________

From report at bugs.python.org  Mon May 24 20:17:21 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:17:21 +0000
Subject: [issue8804] http.client should support SSL contexts
In-Reply-To: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>
Message-ID: <1274725041.12.0.814965769316.issue8804@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8804>
_______________________________________

From report at bugs.python.org  Mon May 24 20:41:08 2010
From: report at bugs.python.org (Andrej Krpic)
Date: Mon, 24 May 2010 18:41:08 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1274726468.48.0.212042734036.issue8142@psf.upfronthosting.co.za>


Changes by Andrej Krpic <akrpic77 at gmail.com>:


----------
nosy: +akrpic77
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon May 24 20:46:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 18:46:48 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274726808.42.0.612459664592.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that implements Mark's timedelta_arith.py algorithms in C.

With rounding well defined, I am close to withdrawing my opposition to supporting mixed timedelta with float operations.  There is still one issue that I believe is worth discussing before this feature is accepted.  Time, unlike most other physical quantities has a non-arbitrary notion of direction.  Therefore, in many applications, rounding towards past or towards future may be preferable to rounding to nearest.

For example, one of the likely applications of floating point division would be to construct time series from continuous or differently sampled functions.  If such series are used to measure correlations between cause and effect, it is important that effect is measured at a time following the cause and not at an early or the same moment.

As Mark noted in private correspondence, this issue is mitigated by the fact that "with correct rounding, for timedeltas t and s, and a positive float x, it is guaranteed that t <= s implies t op x <= s op x" (where op is either * or /).  It is still possible however, that even the case of t < s and t op x == s op x present a problem in some applications.

Despite this issue, I would support round to nearest even choice over round to past or to future mainly because it is less likely to lead to surprises where (d1/d2) * d2 != d1.  This choice also conforms with the round() builtin definition and is somewhat more difficult to implement right using existing means.

Daniel, would you like to chime in on the questions of how the results of these operations should be rounded?

If I don't hear principle objections from the "nosy" list, I'll add a documentation patch.

----------
Added file: http://bugs.python.org/file17450/issue1289118-nodoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 24 20:48:26 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 18:48:26 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274726906.11.0.0574287272309.issue8806@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm assigning this one to me.
Btw, before writing anything I think it would be better to decide what to do first, possibly by adopting the same approach everywhere (smtplib, imaplib, poplib, urllib and http.client).

My proposal: 

- the user should still be able to use keyfile and certfile if desired, they're quicker to use and backward compatibility must be maintained.

- SSL context can be provided by passing a new "context" argument to the constructor.

- if context arg is passed FTP_TLS.ssl_version should be ignored and SSLContext.protocol used instead

- keyfile/certfile and context arguments should be mutually exclusive (ValueError)


Makes sense?

----------
assignee:  -> giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Mon May 24 20:56:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 18:56:25 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274726906.11.0.0574287272309.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274727379.3200.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My proposal: 
> 
> - the user should still be able to use keyfile and certfile if desired, they're quicker to use and backward compatibility must be maintained.
> 
> - SSL context can be provided by passing a new "context" argument to the constructor.
> 
> - if context arg is passed FTP_TLS.ssl_version should be ignored and SSLContext.protocol used instead
> 
> - keyfile/certfile and context arguments should be mutually exclusive (ValueError)
> 
> 
> Makes sense?

Entirely sense to me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Mon May 24 21:50:03 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 24 May 2010 19:50:03 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274730603.91.0.569804569669.issue1289118@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I don't have a strong feeling about the method of rounding.  My thinking is: If my application is sensitive to how the last microsecond is rounded, then I shouldn't be using a type that only gives me 1-microsecond precision.

(Likewise, if my application is sensitive to how the last binary digital of the floating point mantissa is rounded ... I'm in trouble)

That said, round-to-nearest strikes me as the least-surprising approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 24 21:57:09 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 24 May 2010 19:57:09 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

The docs of sqlite3 for python 3.0 and 3.1 seems to be written for python 2.6 and hence wrong at many places.
like, 
>>> for member in r: print member 

However the docs for sqlite3 in py3k trunk seems fine. The sqlite3 doc in py3k trunk should be used in these places.

http://docs.python.org/release/3.0.1/library/sqlite3.html
http://docs.python.org/release/3.1/library/sqlite3.html

----------
assignee: docs at python
components: Documentation
files: sqlite.rst.patch
keywords: patch
messages: 106382
nosy: docs at python, georg.brandl, ghaering, l0nwlf
priority: normal
severity: normal
status: open
title: fixing sqlite3 docs for py3k
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17451/sqlite.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Mon May 24 21:58:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 May 2010 19:58:59 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274731139.33.0.382735390494.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re rounding:  I'll just note that timedelta / timedelta -> float currently does round to nearest;  I'd find it quite surprising if float * timedelta -> timedelta didn't round to nearest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 24 22:18:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 May 2010 20:18:49 +0000
Subject: [issue1168427] Possible windows+python bug
Message-ID: <1274732329.5.0.0038349680434.issue1168427@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1168427>
_______________________________________

From report at bugs.python.org  Mon May 24 22:23:05 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 20:23:05 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274732585.01.0.990936876077.issue8806@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file17452/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Mon May 24 22:36:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 May 2010 20:36:14 +0000
Subject: [issue8016] Support for cp858
In-Reply-To: <1267057078.57.0.378294218982.issue8016@psf.upfronthosting.co.za>
Message-ID: <1274733374.13.0.683845414807.issue8016@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

A new codec is quite self-contained, so that's ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8016>
_______________________________________

From report at bugs.python.org  Mon May 24 22:44:37 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 24 May 2010 20:44:37 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1274733877.04.0.796457163078.issue8800@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

You're definitely right that posix and java don't make these usable from the normal lock API. And I don't think it's essential that they be usable as RLocks, although it's nice for Conditions. I think what I'm actually saying is that, if you have an acquire() operation on RWLock, then it has to forward to the write lock. Forwarding to the read lock would have different semantics from RLock.acquire (2 threads could get in at once) and so would be incorrect.

I agree that RWLock is more obvious. As long as the docs mention that it's equivalent to a shared/exclusive lock, I don't care that much about the name. Just throwing out ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Mon May 24 22:44:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 20:44:41 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
In-Reply-To: <1274731139.33.0.382735390494.issue1289118@psf.upfronthosting.co.za>
Message-ID: <AANLkTinDUroNb83AVpGisFl0IYxtcEVtsXtXO2gryTv5@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like we have a consensus on the rounding mode.  Note, however
that timedelta constructor rounds away from zero at least on
Intel/MacOS X:

[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Should this be considered a bug?

For comparison,

[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 24 22:48:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 May 2010 20:48:31 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274734111.5.0.748178035141.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Alexander, it looks like Roundup ate some of your message there. :)

Yes, ideally I'd say that the constructor should be doing round-half-to-even.  Though last time I looked, the constructor looked quite complicated (especially for float inputs);  it may not be feasible to fix this easily.

At any rate, we should open a separate issue for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 24 22:55:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 20:55:01 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274734501.23.0.244623376207.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Indeed.  Here is what I intended:

"""
>>> from datetime import timedelta as d
>>> [d(microseconds=i + .5)//d.resolution for i in range(-10,10)]
[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Should this be considered a bug?

For comparison,

>>> [d.resolution*(i+0.5)//d.resolution for i in range(-10,10)]
[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

and
>>> [round(i+0.5) for i in range(-10,10)]
[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]
"""

I checked the documentation and while it says: "If any argument is a float and there are fractional microseconds, the fractional microseconds left over from all arguments are combined and their sum is rounded to the nearest microsecond." it does not specify how half-integers should be handled.

While it may not be a bug in strict sense, it looks like the code in question can be improved.  I'll open a separate issue for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 24 23:00:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 21:00:04 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274732585.01.0.990936876077.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274734799.3200.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Patch in attachment.

You could add checks for:

    self.assertIs(self.client.sock.context, ctx)
[...]
    self.assertIs(sock.context, ctx)

(I know, the "context" attribute isn't documented, I'm going to fix
this)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Mon May 24 23:00:31 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 May 2010 21:00:31 +0000
Subject: [issue8812] Show package path in repr string for packages installed
	to user site
In-Reply-To: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>
Message-ID: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I see this in Python 2.7. No idea if this is a regression, mere future request, but doesn't it make sense to print the value `__path__` in the repr string?

>>> import paste
>>> paste
<module 'paste' (built-in)>
>>> paste.__path__
['/home/sridharr/.local/lib/python2.7/site-packages/paste']

It does for stdlib packages/modules:

>>> import xml
>>> xml
<module 'xml' from '/opt/ActivePython-2.7/lib/python2.7/xml/__init__.pyc'>

Happens on Windows, Linux and Mac using Python 2.7 hg hash eaeebf8cda33.0.

----------
components: Library (Lib)
messages: 106391
nosy: srid
priority: normal
severity: normal
status: open
title: Show package path in repr string for packages installed to user site
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8812>
_______________________________________

From report at bugs.python.org  Mon May 24 23:16:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 May 2010 21:16:27 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1274735787.54.0.76430416096.issue3143@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed the sidebar.js to Sphinx trunk.  When Python switches to 1.0, we can activate the option to use it.  Thanks Ezio!

----------
resolution:  -> remind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Mon May 24 23:17:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 21:17:10 +0000
Subject: [issue8813] SSLContext doesn't support loading a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

SSL Context should support loading a CRL. See M2Crypto patches:
https://bugzilla.osafoundation.org/show_bug.cgi?id=12954
https://bugzilla.osafoundation.org/show_bug.cgi?id=11694

Or PyOpenSSL branch supporting CRL:
https://launchpad.net/~rick-fdd/pyopenssl/crl_and_revoked

----------
components: Library (Lib)
messages: 106393
nosy: haypo
priority: normal
severity: normal
status: open
title: SSLContext doesn't support loading a CRL
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8813>
_______________________________________

From report at bugs.python.org  Mon May 24 23:17:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 21:17:17 +0000
Subject: [issue8813] SSLContext doesn't support loading a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1274735837.19.0.69487297961.issue8813@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8813>
_______________________________________

From report at bugs.python.org  Mon May 24 23:20:59 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 24 May 2010 21:20:59 +0000
Subject: [issue8814] functools.WRAPPER_ASSIGNMENTS should include
	__annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

__annotations__ should be included in the set of attributes copied by default to a wrapped method.

An example of the problem:
>>> from functools import wraps
>>> def mydecorator(fn):
...     @wraps(fn)
...     def inner(*args, **kwargs):
...         return fn(*args, **kwargs)
...     return inner
...
>>> @mydecorator
... def foo(a:int, b:str):
...     pass
... 
>>> foo.__annotations__
{}

With the included fix:
>>> foo.__annotations__
{'a': <class 'int'>, 'b': <class 'str'>}

----------
components: Library (Lib)
files: functools-wrapper-assign-annotations.diff
keywords: patch
messages: 106394
nosy: terrence
priority: normal
severity: normal
status: open
title: functools.WRAPPER_ASSIGNMENTS should include __annotations__
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17453/functools-wrapper-assign-annotations.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8814>
_______________________________________

From report at bugs.python.org  Mon May 24 23:21:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 May 2010 21:21:11 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1274736071.54.0.43314942381.issue6662@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Mon May 24 23:28:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 May 2010 21:28:09 +0000
Subject: [issue8813] SSLContext doesn't support loading a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1274736489.16.0.19472359963.issue8813@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8813>
_______________________________________

From report at bugs.python.org  Mon May 24 23:29:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 May 2010 21:29:22 +0000
Subject: [issue8016] Support for cp858
In-Reply-To: <1267057078.57.0.378294218982.issue8016@psf.upfronthosting.co.za>
Message-ID: <1274736562.07.0.41816895376.issue8016@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks all, committed in r81499.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8016>
_______________________________________

From report at bugs.python.org  Mon May 24 23:33:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 24 May 2010 21:33:02 +0000
Subject: [issue8814] functools.WRAPPER_ASSIGNMENTS should include
	__annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1274736782.55.0.999782979915.issue8814@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patch is fine. Can you check if some doc has to be updated to mention that? (files under Doc and docstrings in functools.py).

Removing 3.1 since this is a new feature, and 3.3 since 3.2 is not frozen.

----------
nosy: +merwok
versions:  -Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8814>
_______________________________________

From report at bugs.python.org  Mon May 24 23:37:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 May 2010 21:37:15 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1274737035.01.0.560227638418.issue8616@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, it seems that round_dance and scribble don't work with the 2.7 turtle version?  I played a round of nim, but although I took the last stick, it said the computer won...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8616>
_______________________________________

From report at bugs.python.org  Mon May 24 23:38:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 May 2010 21:38:07 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1274737087.17.0.734206306796.issue8616@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed the turtleDemo_27b1_to_turtleDemo.diff in r81502.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8616>
_______________________________________

From report at bugs.python.org  Mon May 24 23:44:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 24 May 2010 21:44:54 +0000
Subject: [issue8812] Show package path in repr string for packages installed
	to user site
In-Reply-To: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>
Message-ID: <1274737494.58.0.365981209898.issue8812@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

You are mistaken. It doesn't include __path__ into repr, but __file__. It prints "(built-in)" if the filename is not set for some reason.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8812>
_______________________________________

From report at bugs.python.org  Mon May 24 23:46:29 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 24 May 2010 21:46:29 +0000
Subject: [issue8324] add a distutils test command
In-Reply-To: <1270509574.31.0.218772255625.issue8324@psf.upfronthosting.co.za>
Message-ID: <1274737589.89.0.903644429301.issue8324@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8324>
_______________________________________

From report at bugs.python.org  Mon May 24 23:48:35 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 May 2010 21:48:35 +0000
Subject: [issue8812] Show package path in repr string for packages installed
	to user site
In-Reply-To: <1274737494.58.0.365981209898.issue8812@psf.upfronthosting.co.za>
Message-ID: <2249CE29-FC0B-4AF8-8B25-6D9C2D049B06@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-05-24, at 2:44 PM, Martin v. L?wis wrote:

> You are mistaken. It doesn't include __path__ into repr, but __file__. It prints "(built-in)" if the filename is not set for some reason.

Ok. Why is __file__ not set for modules/packages installed to user site (~/.local/), but not stdlib? Is this a bug?

Ah, I see that a "__init__.py" is missing in these packages.   Strange; gotta see how that happened in first place ..  (even stranger that I can actually import these directories...)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8812>
_______________________________________

From report at bugs.python.org  Mon May 24 23:48:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 21:48:51 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1274737731.94.0.92639025065.issue6662@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: 2.7 (r81500, r81501), 2.6 (r81503), 3.2 (r81504), 3.1 (r81505).

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Mon May 24 23:48:54 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 24 May 2010 21:48:54 +0000
Subject: [issue8814] functools.WRAPPER_ASSIGNMENTS should include
	__annotations__
In-Reply-To: <1274736059.05.0.616257463555.issue8814@psf.upfronthosting.co.za>
Message-ID: <1274737734.44.0.518016685224.issue8814@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

Thank you for looking it over!  The updated patch adds __annotations__ to the documentation where the value of WRAPPER_ASSIGNMENTS is given.  I think it would be nice if the documentation showed WRAPPER_ASSIGNMENTS and WRAPPER_UPDATES in their own section, but that would probably merit a separate issue to fix, if it is even worth bothering with.

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file17454/functools-wrapper-assign-annotations.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8814>
_______________________________________

From report at bugs.python.org  Mon May 24 23:52:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 24 May 2010 21:52:07 +0000
Subject: [issue8142] libffi update to 3.0.9
In-Reply-To: <1268610005.87.0.424920826618.issue8142@psf.upfronthosting.co.za>
Message-ID: <1274737927.18.0.529354428882.issue8142@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8142>
_______________________________________

From report at bugs.python.org  Mon May 24 23:54:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 21:54:50 +0000
Subject: [issue8813] SSLContext doesn't support loading a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1274738090.36.0.41864567589.issue8813@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8813>
_______________________________________

From report at bugs.python.org  Tue May 25 00:00:33 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 May 2010 22:00:33 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274738433.24.0.364690286716.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attaching a new patch by Rafe against Python 2.7. Unfortunately with 2.7 striving for an RC next, this should only target Python 3.2 and not 2.7.

----------
versions: +Python 3.2 -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17455/next-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 00:00:40 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 May 2010 22:00:40 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274738440.82.0.235411675189.issue5094@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file13023/datetime-utc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 00:00:44 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 May 2010 22:00:44 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274738444.73.0.175675565843.issue5094@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file13029/datetime-utc-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 00:43:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 22:43:18 +0000
Subject: [issue8815] 65001
Message-ID: <1274740998.1.0.335248912242.issue8815@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: haypo
priority: normal
severity: normal
status: open
title: 65001

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8815>
_______________________________________

From report at bugs.python.org  Tue May 25 00:43:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 22:43:41 +0000
Subject: [issue8815] 65001
In-Reply-To: <1274741021.43.0.916681984893.issue8815@psf.upfronthosting.co.za>
Message-ID: <1274741021.43.0.916681984893.issue8815@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

oops, sorry.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8815>
_______________________________________

From report at bugs.python.org  Tue May 25 00:46:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 24 May 2010 22:46:41 +0000
Subject: [issue8812] Show package path in repr string for packages installed
	to user site
In-Reply-To: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>
Message-ID: <1274741201.92.0.280485875108.issue8812@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please provide a reproducible bug report? I have no idea what "paste" is or how it got into your .local folder. Please structure the bug report as follows:

1. this is what you did
2. this is what happened
3. this is what you expected to happen instead

Installing http://pypi.python.org/pypi/Paste through distribute's setup.py install --user, I get

py> paste
<module 'paste' from '/home/martin/.local/lib/python/2.7/site-packages/Paste-1.7.3.1-py2.7.egg/paste/__init__.pyc'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8812>
_______________________________________

From report at bugs.python.org  Tue May 25 01:01:47 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 May 2010 23:01:47 +0000
Subject: [issue8812] Show package path in repr string for packages installed
	to user site
In-Reply-To: <1274741201.92.0.280485875108.issue8812@psf.upfronthosting.co.za>
Message-ID: <F2B2998A-92CE-40F2-B417-C88E1C49DF25@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-05-24, at 3:46 PM, Martin v. L?wis wrote:

> Can you please provide a reproducible bug report? I have no idea what "paste" is or how it got into your .local folder. Please structure the bug report as follows:
> 
> 1. this is what you did
> 2. this is what happened
> 3. this is what you expected to happen instead

I was not sure if this is a bug .. which is why I was waiting till the completion of my investigation ...

> 
> Installing http://pypi.python.org/pypi/Paste through distribute's setup.py install --user, I get
> 
> py> paste
> <module 'paste' from '/home/martin/.local/lib/python/2.7/site-packages/Paste-1.7.3.1-py2.7.egg/paste/__init__.pyc'>

This is what I found: setuptools/Distribute does some namespace magic to make these namespace packages work in the absence of __init__.py. You should be able to reproduce this with --root option (or --single-version-multi-installed or some such thing) in "setup.py install" command to prevent .egg'fying the installed packages. So this is not a bug in Python; it is an expected behaviour of setuptools-installed packages that do not use .egg/ package structure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8812>
_______________________________________

From report at bugs.python.org  Tue May 25 01:02:40 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 May 2010 23:02:40 +0000
Subject: [issue8812] Show package path in repr string for packages installed
	to user site
In-Reply-To: <1274734830.9.0.699148777816.issue8812@psf.upfronthosting.co.za>
Message-ID: <1274742160.93.0.293894122978.issue8812@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8812>
_______________________________________

From report at bugs.python.org  Tue May 25 01:07:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 24 May 2010 23:07:07 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274742427.88.0.463903887048.issue8777@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Tue May 25 01:11:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 May 2010 23:11:40 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1274742700.09.0.0322306138351.issue850997@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated version of the patch for py3k:
 - don't accept "ignore" error handler anymore
 - there is a FIXME near "mbcs_decode_error:"

The whole test suite pass with these patch.

----------
Added file: http://bugs.python.org/file17456/mbcs_errors-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850997>
_______________________________________

From report at bugs.python.org  Tue May 25 01:30:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 May 2010 23:30:57 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274743857.79.0.398733573476.issue8811@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Tue May 25 01:37:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 May 2010 23:37:59 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274744279.3.0.468048498712.issue8811@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, the patch mostly doesn't apply for me on the 3.1 branch.  (Note that 3.0 docs aren't maintained anymore, just like 3.0 itself.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Tue May 25 01:39:14 2010
From: report at bugs.python.org (David Antliff)
Date: Mon, 24 May 2010 23:39:14 +0000
Subject: [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1274744354.9.0.748636870163.issue8562@psf.upfronthosting.co.za>


Changes by David Antliff <david.antliff at gmail.com>:


----------
nosy: +David.Antliff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8562>
_______________________________________

From report at bugs.python.org  Tue May 25 01:57:25 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 24 May 2010 23:57:25 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274745445.86.0.157647642215.issue8811@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

ok,
I think a few example codes are wrongly mentioned as if it were 2.x docs, however those examples at http://docs.python.org/dev/py3k/library/sqlite3 works correctly.
Do by 'mostly', do you mean I should submit another patch with only those wrong examples rectified ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Tue May 25 02:00:20 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Tue, 25 May 2010 00:00:20 +0000
Subject: [issue1368368] prompt_user_passwd() in FancyURLopener masks 401
	Unauthorized error page
Message-ID: <1274745620.14.0.0172052434831.issue1368368@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1368368>
_______________________________________

From report at bugs.python.org  Tue May 25 02:49:07 2010
From: report at bugs.python.org (Dan Buch)
Date: Tue, 25 May 2010 00:49:07 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274748547.79.0.379117849846.issue8796@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 25 03:47:13 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Tue, 25 May 2010 01:47:13 +0000
Subject: [issue8816] Add test cases for builtins
In-Reply-To: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>
Message-ID: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

I'm attaching 2 patches with additional test cases for these built-in functions. They are mostly negative tests.

* abs
* callable: trunk only
* len
* long: trunk only
* range: copied some py3k range tests into trunk
* reduce: trunk only
* vars

I'm currently helping port IronPython tests into CPython. This is part of that series.

----------
components: Tests
files: builtins.trunk.patch
keywords: patch
messages: 106410
nosy: gnofi
priority: normal
severity: normal
status: open
title: Add test cases for builtins
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17457/builtins.trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8816>
_______________________________________

From report at bugs.python.org  Tue May 25 03:47:36 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Tue, 25 May 2010 01:47:36 +0000
Subject: [issue8816] Add test cases for builtins
In-Reply-To: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>
Message-ID: <1274752056.79.0.482503347943.issue8816@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file17458/builtins.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8816>
_______________________________________

From report at bugs.python.org  Tue May 25 04:18:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 02:18:14 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274753894.3.0.0455773830184.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have two questions about the proposed implementation:

1. Why not follow pytz lead and expose an instance of UTC rather than the UTC class itself?

2. Is there a real need to add a boolean argument to utcnow()?  I think timedelta.now(UTC()) or with utc = UTC() timedelta.now(utc) seems to be a more obvious way to produce TZ aware datetime.

If a singleton instance utc is exposed instead of UTC class, I would suggest to change its repr to 'datetime.utc'.

On the patch itself, datetime_utcnow() is missing an error check for PyObject_IsTrue() return value:

>>> class X:
...    def __nonzero__(self): raise RuntimeError
... 
>>> datetime.utcnow(tz_aware=X())
datetime.datetime(2010, 5, 25, 2, 12, 14, 739720, tzinfo=<datetime.UTC object at 0x1015aab80>)
XXX undetected error
..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 05:06:40 2010
From: report at bugs.python.org (Rafe Kaplan)
Date: Tue, 25 May 2010 03:06:40 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274756800.67.0.166523412485.issue5094@psf.upfronthosting.co.za>


Rafe Kaplan <rafek at google.com> added the comment:

Alexander, about 1, that's a pretty good question.  I had originally wanted to do something like that but Brett Cannon at the time thought it was not the right approach.  I don't recall the details.  Maybe Brett can recall.  I think we had that conversation in person and it was a long time ago :(

I had originally thought of doing the class, and then having constants associated with it:

  UTC.UTC0

Eventually if we support multiple timezones:

  UTC.UTC1
  UTC.UTC2
  UTC.UTC_1
  UTC.UTC_2

Well... maybe not given how impossible the naming would be.

I think we also talked about redefining new so that it would always return the same global instance.

On 2, we had discussions about how to pass parameters in to utcnow that we DID record.  When I suggested it, Brett said:

  "...using a boolean flag over an argument is much less error-prone for a developer from passing in the wrong timezone object; passing in something other than an instance of UTC would just be stupid so we should make sure the developer isn't stupid. =)"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 05:30:38 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 May 2010 03:30:38 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274758238.41.0.0940304271793.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

We didn't do a singleton because I don't like singletons. =) Plus they muck with isinstance/issubclass if you don't expose the class. Basically there is no need to have it be a singleton, so why bother?

And Rafe is right: since utcnow() already exists, why not take advantage of the method? Yes, you could manually call now() with a UTC object, but people are going to notice the utcnow() method and want to use it, so we should make it easy to use the new UTC object on utcnow(). Plus it has the added benefit of providing a transition plan to make utcnow() always return a timezone-aware datetime object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 05:41:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 03:41:32 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1274756800.67.0.166523412485.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTinuYn7pp2bVgqBl_AYJRzKeUsEOuhmTyNFgOEAb@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan <report at bugs.python.org> wrote:
..
> On 2, we had discussions about how to pass parameters in to utcnow that we DID record. ?When I
> suggested it, Brett said:
>
> ?"...using a boolean flag over an argument is much less error-prone for a developer from passing in the wrong
> timezone object; passing in something other than an instance of UTC would just be stupid so we should make
> sure the developer isn't stupid. =)"

Well, I respectfully disagree.  This advise seems to be placing
convenience of the writer of the code over that of the reader.
Imagine encountering an expression datetime.utcnow(True) allowed by
your current patch and trying to figure out what it means.  This can
be improved by making tz_aware a keyword only argument, but in that
case a separate datetime.tz_aware_utcnow() function seems like a
better choice.

Note that I am not suggesting passing anything to utcnow().  I would
either leave it unchanged or make it always return aware datetime
instances.  (Note that with singleton UTC timezone naive datetime
instances can be deprecated with no performance penalty.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 06:14:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 04:14:30 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274760870.5.0.40046272125.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> We didn't do a singleton because I don't like singletons. =) Plus they
> muck with isinstance/issubclass if you don't expose the class.

I am not sure what you mean by "muck with."  Why would anyone want to subclass UTC?

> Basically there is no need to have it be a singleton, so why bother?

There are several advantages of having all datetime instances with tzinfo=UTC() referring to the same instance:

1. Comparison (and I believe subtraction) of aware datetime instances bypasses calculation of utcoffset if their tzinfo attributes refer to the same object.

2. With the current patch,

>>> set(UTC() for i in range(3))
set([<datetime.UTC object at 0x1015aac80>, <datetime.UTC object at 0x1015aad00>, <datetime.UTC object at 0x101a0e040>])

I don't think this is intended.  Basically UTC() instances cannot be meaningfully compared or used as dictionary or set keys.  You can fix it by providing custom __eq__ and __hash__, but this problem simply goes away if a singleton is exposed instead.

3. now(utc) is slightly more readable than now(UTC())

4. Singleton utc is familiar to pytz users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 06:26:32 2010
From: report at bugs.python.org (Travis Oliphant)
Date: Tue, 25 May 2010 04:26:32 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1274297936.23.0.338219320215.issue3132@psf.upfronthosting.co.za>
Message-ID: <2ACBF75D-0F5C-4227-BDFF-407369CD9062@enthought.com>


Travis Oliphant <oliphant at enthought.com> added the comment:

On May 19, 2010, at 2:38 PM, Mark Dickinson wrote:

> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Travis, this issue is still assigned to you.  Do you plan to work on this at some stage, or may I unassign you?
> 

You may unassign it from me.   Unfortunately, I don't have time anymore to work on it and I don't see that changing in the coming months. 

Thanks,

-Travis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Tue May 25 10:04:31 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 May 2010 08:04:31 +0000
Subject: [issue8787] warnings inside PyRun_SimpleString() display argv[1]
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1274774671.77.0.38204397152.issue8787@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, the warnings module tries to display the file name. Inside PyRun_SimpleString(), globals()['__name__'] == '__main__', and the warnings module supposes that argv[1] is the name of the script.

I wonder whether __file__ would be more accurate: it is filled when running a script, but not when running a string. And sys.argv would not be used any more.

----------
assignee:  -> brett.cannon
nosy: +amaury.forgeotdarc, brett.cannon
title: PySys_Get -> warnings inside PyRun_SimpleString() display argv[1]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Mon May 24 03:42:14 2010
From: report at bugs.python.org (Ionut Turturica)
Date: Mon, 24 May 2010 01:42:14 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>


New submission from Ionut Turturica <jonozzz at yahoo.com>:

The URL I'm trying to open is using basicauth and the username/password is incorrect.

This works flawlessly in 2.6.4.

  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 397, in open
    response = meth(req, response)
  File "/home/jono/work/sites/test123/urllib2.py", line 510, in http_response
    'http', request, response, code, msg, hdrs)
  File "/home/jono/work/sites/test123/urllib2.py", line 429, in error
    result = self._call_chain(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 855, in http_error_401
    url, req, headers)
  File "/home/jono/work/sites/test123/urllib2.py", line 833, in http_error_auth_reqed
    return self.retry_http_basic_auth(host, req, realm)
  File "/home/jono/work/sites/test123/urllib2.py", line 843, in retry_http_basic_auth
    return self.parent.open(req, timeout=req.timeout)
  File "/home/jono/work/sites/test123/urllib2.py", line 391, in open
    response = self._open(req, data)
  File "/home/jono/work/sites/test123/urllib2.py", line 409, in _open
    '_open', req)
  File "/home/jono/work/sites/test123/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/home/jono/work/sites/test123/urllib2.py", line 1169, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/home/jono/work/sites/test123/urllib2.py", line 1107, in do_open
    h = http_class(host, timeout=req.timeout) # will parse host:port
  File "/usr/lib64/python2.6/httplib.py", line 1104, in __init__
    HTTPConnection.__init__(self, host, port, strict, timeout)
  File "/usr/lib64/python2.6/httplib.py", line 660, in __init__
    self._set_hostport(host, port)
  File "/usr/lib64/python2.6/httplib.py", line 689, in _set_hostport
    if host and host[0] == '[' and host[-1] == ']':
RuntimeError: maximum recursion depth exceeded in cmp

----------
components: Library (Lib)
messages: 106342
nosy: jonozzz
priority: normal
severity: normal
status: open
title: urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8797>
_______________________________________

From report at bugs.python.org  Tue May 25 10:22:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 08:22:16 +0000
Subject: [issue8816] Add test cases for builtins
In-Reply-To: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>
Message-ID: <1274775736.69.0.341479285755.issue8816@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for these;  I'll commit them later.

Aren't the extra range tests that you added already in trunk?

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8816>
_______________________________________

From report at bugs.python.org  Tue May 25 10:33:45 2010
From: report at bugs.python.org (Sebastian)
Date: Tue, 25 May 2010 08:33:45 +0000
Subject: [issue8787] warnings inside PyRun_SimpleString() display argv[1]
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1274776425.12.0.605276567769.issue8787@psf.upfronthosting.co.za>


Sebastian <python.10.webmaster at spamgourmet.com> added the comment:

Oh, damn. I really forgot the argv filename thing. Nevermind :)

But back to topic. __file__ might be not the best solution for that. What does Python when embedded, and __file__ is not set? That can happen when the source of your code is not a file (multiline textbox, ...)

I would simply follow the way how the traceback solves this. Just print out the filename passed to:

Py_CompileStringFlags(const char *str, const char *filename, int start, PyCompilerFlags *flags)
PyRun_SimpleFileExFlags(FILE *fp, const char *filename, int closeit, PyCompilerFlags *flags)
[...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Tue May 25 11:06:07 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 25 May 2010 09:06:07 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1274778367.25.0.91368443874.issue7511@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Remarks with the patch:

- we need to keep the find_vcvarsall() backward compatible. e.g. define a default value for arch.

- Next, since this fix is specific to 64bt and since *any value* in arch will be used as "not 64 bits", I think the patch should be using a boolean tag instead (vs64bits=False).

- Last, we need a unit test that runs exclusively in this environment, to demonstrate that youyr fix fixes the error.

Let me know if you want to work on the patch, or I can fix it directly.
I'd prefer of course if you modify the patch ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue May 25 11:10:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 09:10:12 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274778612.84.0.772721565435.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

By the way, does your patch do the right thing for

timedelta(microseconds=1) / -4.0

?  Because my Python code doesn't.  :) [If n is negative, then the 2*r > n condition in div_nearest should be 2*r < n instead.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue May 25 11:45:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 May 2010 09:45:22 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <AANLkTinuYn7pp2bVgqBl_AYJRzKeUsEOuhmTyNFgOEAb@mail.gmail.com>
Message-ID: <1274780715.3174.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note that I am not suggesting passing anything to utcnow().  I would
> either leave it unchanged or make it always return aware datetime
> instances.

The latter would break compatibility, though (especially given how
comparison between "naive" and "aware" datetimes raises an error...).

I also agree with Brett that a singleton looks rather unnecessary (it
also look quite C++/Java-esque to me).

On the subject of the patch:
- Alexander spotted the PyObject_IsTrue() issue
- you should never use tabs (anymore), only 4 spaces
- lines like:
    self.assertTrue(isinstance(now.tzinfo, UTC))
can be rewritten as
    self.assertIsInstance(now.tzinfo, UTC)
- here, I'm not sure why you're using "UTC" as the error message
(copy/paste error?):
    self.assertEquals(None, meth(False).tzinfo, UTC)
- you might make the UTC class subclassable, although I'm not sure
there's any point

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 11:48:42 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 25 May 2010 09:48:42 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274780922.01.0.660779443952.issue8770@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

added in r81513 

Thanks all !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Tue May 25 11:48:54 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 25 May 2010 09:48:54 +0000
Subject: [issue8770] Make 'python -m sysconfig' print something useful
In-Reply-To: <1274308998.81.0.84185176486.issue8770@psf.upfronthosting.co.za>
Message-ID: <1274780934.88.0.41686400697.issue8770@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8770>
_______________________________________

From report at bugs.python.org  Tue May 25 12:35:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 May 2010 10:35:50 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1274783750.1.0.915992210218.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

shlex in 3.x works with Unicode strings. Is it still time to try to fix this bug for 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Tue May 25 13:07:10 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Tue, 25 May 2010 11:07:10 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274785630.14.0.304446803384.issue5689@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

I'm the author of the pyliblzma module, and if desired, I'd be happy to help out adapting pyliblzma for inclusion with python.
Most of it's code is based on bz2module.c, so it shouldn't be very far away from being good 'nuff.
What I see as required is:
* clean out use of C99 types etc.
* clean up the LZMAOptions class (this is the biggest difference from the bz2 module, as the filter supports a wide range of various options, everything related such as parsing, api documentation etc. was placed in it's own class, I've yet to receive any feedback on this decission or find any remote equivalents out there to draw inspiration from;)
* While most of the liblzma API has been implemented, support for multiple/alternate filters still remains to be implemented. When done it will also cause some breakage with the current pyliblzma API.

I plan on doing these things sooner or later anyways, it's pretty much just a matter of motivation and priorities standing in the way, actual interest from others would certainly have a positive effect on this. ;)

For other alternatives to the LGPL liblzma, you really don't have any, keep in mind that LZMA is "merely" the algorithm, while xz (and LZMA_alone, used for '.lzma', now obsolete, but still supported) are the actual format you want support for. The LZMA SDK does not provide any compatibility for this.

----------
nosy: +proyvind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Tue May 25 13:14:24 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Tue, 25 May 2010 11:14:24 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274786064.56.0.276229499658.issue5689@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

ps: pylzma uses the LZMA SDK, which is not what you want.
pyliblzma (not the same module;) OTOH uses liblzma, which is the library used by xz/lzma utils

You'll find it available at http://launchpad.net/pyliblzma

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Tue May 25 13:20:30 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Tue, 25 May 2010 11:20:30 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274786430.47.0.309645060137.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

Ooops, I kinda should've commented on this issue here in stead, rather than in issue5689, so I'll just copy-paste it here as well:

I'm the author of the pyliblzma module, and if desired, I'd be happy to help out adapting pyliblzma for inclusion with python.
Most of it's code is based on bz2module.c, so it shouldn't be very far away from being good 'nuff.
What I see as required is:
* clean out use of C99 types etc.
* clean up the LZMAOptions class (this is the biggest difference from the bz2 module, as the filter supports a wide range of various options, everything related such as parsing, api documentation etc. was placed in it's own class, I've yet to receive any feedback on this decission or find any remote equivalents out there to draw inspiration from;)
* While most of the liblzma API has been implemented, support for multiple/alternate filters still remains to be implemented. When done it will also cause some breakage with the current pyliblzma API.

I plan on doing these things sooner or later anyways, it's pretty much just a matter of motivation and priorities standing in the way, actual interest from others would certainly have a positive effect on this. ;)

For other alternatives to the LGPL liblzma, you really don't have any, keep in mind that LZMA is "merely" the algorithm, while xz (and LZMA_alone, used for '.lzma', now obsolete, but still supported) are the actual format you want support for. The LZMA SDK does not provide any compatibility for this.

----------
nosy: +proyvind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue May 25 13:27:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 May 2010 11:27:46 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1274786866.68.0.14967502969.issue8765@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The 3.1 version does it correctly since issue7785, but this was not backported to 2.x.
Python 3.x uses the "y*" format code to accept bytes and not unicode; this code does not exist in 2.x, and was replaced with "s*", which accepts unicode.
But since the io module is designed up front to forbid default conversion between bytes and unicode, I think it's safe to change the code as suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Tue May 25 13:44:59 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Tue, 25 May 2010 11:44:59 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1274787899.54.0.689696358865.issue8616@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

Yes, tdemo_raund_dance.py and tdemo_scribble.py definitely do not work
with turtle.py from Python 2.7 :-(
I submitted them expecting, that my backport of turtle.py from Python 3.1 to Python 2.7 would be accepted. But, alas, I was too late :-(((

So it's definitely ok not to add it to the turtle-demo-collection.

The case of tdemo_nim.py is a mystery to me. To be sure to use the incriminated version I downloaded it from here (bug-tracker) and tried it out several times. The malfunction you mentioned never did occur. 

Moreover I've checked the code. Ther are only two lines, 62 (initialization with None) and 72, containing assignments to the NimModel.winner attribute which decides about the winner's announcement. Cannot imagine why this shouldn't work correctly?

In fact the very same script is contained in Demo/turtle of Python 3.1.2 (in fact since 3.1) and up to now I never got any feedback about any malfunction whatever. So please could you check it once again and give some information in oder to be able to reproduce the effect mentioned? I'm definitely very interested in *know*ing if the script is faulty or not.

However, committing this demo script or not can safely be regarded as a very unimportant issue. 

Regards, Gregor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8616>
_______________________________________

From report at bugs.python.org  Tue May 25 14:05:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 May 2010 12:05:04 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274789104.9.0.673870523872.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I will happily review any implementation, and I can help with inclusion into python trunk.

> ...the LGPL liblzma...

Can you check which licences cover the different parts of the module?  I think that you will have to contribute your code under the Python Contributor Agreement; and I just grabbed some copy of the "xz-utils" source package, and it states that "liblzma is in the public domain".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue May 25 14:56:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 12:56:02 +0000
Subject: [issue8817] Expose round-to-nearest division algorithm in
	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The implementation of 'round' for Python integers uses a round-to-nearest form of divmod:  a, b -> q, r, where q is the nearest integer to a / b and r = a - b*q.

This form of divmod would be useful elsewhere.  In particular, it's currently needed for implementing multiplication and division of timedeltas by a float:  see issue 1289118  .

This patch exposes the operation to Python C code as _PyLong_Divmod_Near, and refactors long_round to use this operation.

----------
assignee: mark.dickinson
files: div_nearest.patch
keywords: patch
messages: 106431
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Expose round-to-nearest division algorithm in Objects/longobject.c
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17459/div_nearest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8817>
_______________________________________

From report at bugs.python.org  Tue May 25 14:57:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 12:57:45 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274792265.06.0.402512881543.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a patch in issue 8817 that exposes a round-to-nearest form of divmod in a function called _PyLong_Divmod_Near;  this would save on duplication of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue May 25 15:06:37 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Tue, 25 May 2010 13:06:37 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274792797.69.0.309297280409.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

ah, you're right, I forgot that the license for the library had changed as well (motivated by attempt of pleasing BSD people IIRC;), in the past the library was LGPL while only the 'xz' util was public domain..

For my code, feel free to use your own/any other license you'd like or even public domain (if the license of bz2module.c that much of it's derived from permits of course)!

I guess everyone should be happy now then. :)

Btw. for review, I think the code already available should be pretty much good 'nuff for an initial review. Some feedback on things not derived from bz2module.c would be nice, especially the LZMAOptions class would be nice as it's where most of the remaining work required for adding additional filters support. Would kinda blow if I did the work using an approach that would be dismissed as utterly rubbish. ;)

Oh well, it's out there available for anyone already, I probably won't(/shouldn't;) have time for it in a month at least, do as you please meanwhile. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue May 25 15:18:45 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 25 May 2010 13:18:45 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274793525.57.0.332769560709.issue6715@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue May 25 15:23:09 2010
From: report at bugs.python.org (dudologist)
Date: Tue, 25 May 2010 13:23:09 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1274793789.6.0.105826315969.issue6641@psf.upfronthosting.co.za>


dudologist <dudologist at yahoo.co.nz> added the comment:

If %z works only in certain circumstances that behaviour should be documented wherever %z is referred to.

----------
nosy: +dudologist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue May 25 16:31:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 14:31:36 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274797896.63.0.593296415416.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> By the way, does your patch do the right thing for

> timedelta(microseconds=1) / -4.0

No.

>>> timedelta(microseconds=1) / -4.0
datetime.timedelta(-1, 86399, 999999)

(I just copied your python algorithm ...)

I will merge with issue 8817 patch and that should fix the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue May 25 16:32:31 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 14:32:31 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1274797951.34.0.596520057816.issue8653@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Maybe he's referring to the fact that 'default_scheme' is referenced in the docs but in fact the parameter name is 'scheme'?

----------
nosy: +adamnelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Tue May 25 16:34:57 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 14:34:57 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1274798097.98.0.954124909604.issue8143@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I would vote to close this and focus any code cleanliness work on 3.x.  The deep import is more trouble than it's worth.

----------
nosy: +adamnelson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Tue May 25 16:40:20 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 14:40:20 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

urlsplit and urlparse place the host into the path when using a default scheme:

(Pdb) urlsplit('regionalhelpwanted.com/browseads/?sn=2',scheme='http')
SplitResult(scheme='http', netloc='', path='regionalhelpwanted.com/browseads/', query='sn=2', fragment='')

When using default_scheme as referenced in the documentation, it simply doesn't work:

(Pdb) urlsplit('regionalhelpwanted.com/browseads/?sn=2',default_scheme='http')
*** TypeError: urlsplit() got an unexpected keyword argument 'default_scheme'

----------
components: Library (Lib)
messages: 106438
nosy: adamnelson
priority: normal
severity: normal
status: open
title: urlsplit and urlparse add extra slash when using scheme
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 16:40:29 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 14:40:29 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274798429.3.0.408743013696.issue8818@psf.upfronthosting.co.za>


Changes by AdamN <adam at varud.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 17:10:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 15:10:15 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274800215.93.0.739162475612.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching a combined issue1289118 + issue8817 patch.  Datetime code now uses issue8817's _PyLong_Divmod_Near.

----------
Added file: http://bugs.python.org/file17460/issue1289118+issue8817-nodoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Tue May 25 17:21:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 15:21:47 +0000
Subject: [issue8143] urlparse has a duplicate of urllib.unquote
In-Reply-To: <1268615209.69.0.546736476896.issue8143@psf.upfronthosting.co.za>
Message-ID: <1274800907.83.0.960768475388.issue8143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I synced the two versions in r81518 and added a comment to both about updating the other.

----------
resolution:  -> wont fix
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8143>
_______________________________________

From report at bugs.python.org  Tue May 25 17:34:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 May 2010 15:34:25 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1274786430.47.0.309645060137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274801660.3172.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

> I'm the author of the pyliblzma module, and if desired, I'd be happy
> to help out adapting pyliblzma for inclusion with python.
> Most of it's code is based on bz2module.c, so it shouldn't be very far
> away from being good 'nuff.

Well, I wouldn't say bz2module is the best module out there, but as you
say it's probably good enough :) And we can help you fix things if
needed.

Is pyliblzma compatible with Python 3.x? It's too late to incorporate
any new feature in Python 2.x now.

> * While most of the liblzma API has been implemented, support for
> multiple/alternate filters still remains to be implemented. When done
> it will also cause some breakage with the current pyliblzma API.

Hmm, then perhaps you should first fix the current API so that adding
new features doesn't force you to break the API again. There are strict
rules for API breakage in the standard library.

By the way, adding a new module to the stdlib probably requires writing
a PEP (Python Enhancement Proposal). I wouldn't expect this very
proposal to be controversial, but someone has to do it.

Finally, when a module is in the stdlib, it is expected that maintenance
primarily happens in the Python SVN (or Mercurial) tree. We have a
couple of externally-maintained modules, but they're a source of
problems for us.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Tue May 25 17:36:10 2010
From: report at bugs.python.org (Sebastian)
Date: Tue, 25 May 2010 15:36:10 +0000
Subject: [issue8787] warnings inside PyRun_SimpleString() display argv[1]
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1274801770.21.0.3730510883.issue8787@psf.upfronthosting.co.za>


Sebastian <python.10.webmaster at spamgourmet.com> added the comment:

attached a patch for this issue now.

Now it first uses the name of the script,
instead of __file__.

----------
keywords: +patch
Added file: http://bugs.python.org/file17461/_warnings.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Tue May 25 17:37:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 15:37:23 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274801843.47.0.255591080902.issue8818@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The keyword in the code is 'scheme'.  I've updated the docs accordingly in r81521 and r81522.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 18:11:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 16:11:06 +0000
Subject: [issue8817] Expose round-to-nearest division algorithm in
	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274803866.96.0.689884701896.issue8817@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Just a few nitpicks on the patch (in increasing pickiness):

1. Any reason to prefer PyTuple_SetItem to PyTuple_SET_ITEM at the end of _PyLong_Divmod_Near?   You are filling a brand new tuple, so PyTuple_SET_ITEM seems to be more appropriate.

2. temp = (quo_is_neg ? long_add : long_sub)(..) is clever, but IMO is less readable than 

if (quo_is_neg)
   temp = long_add(..)
else
   temp = long_sub(..)

The later form may also be more optimization friendly, particularly if compiler wants to inline static long_add or long_sub.

3. Given that arguments are named 'a' and 'b' it is a bit confusing to have local variable c of a different type.  I think 'cmp' would be a better choice.

4. I see that you removed a comment that displays round() implemented in python.  I think it would be helpful to preserve it for documentation and testing purposes even though the actual algorithm is slightly different.  As long as the results are the same, it is helpful to have reference python code.

5. Similarly to #4, having python implementation of divmod_near() displayed somewhere will be helpful.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8817>
_______________________________________

From report at bugs.python.org  Tue May 25 18:23:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 16:23:11 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1274780715.3174.7.camel@localhost.localdomain>
Message-ID: <AANLkTimdKQHzreB5BZkUE6ZZWT2xq45e2ltVOHahNaf9@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, May 25, 2010 at 5:45 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> I also agree with Brett that a singleton looks rather unnecessary (it
> also look quite C++/Java-esque to me).
>

I still don't understand your aversion to singletons and you did not
address any of the advantages that I listed in my previous comment.  I
don't think singletons are foreign to Python: after all we write None
rather than NoneType() .

We can reach a middle ground by interning UTC instances behind the
scenes so that UTC() is UTC() will always be true.  This will address
most of the issues that I raised and utc = datetime.UTC() is simple
enough to write as long as you don't have to worry about sharing utc
instance between modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 18:45:53 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 25 May 2010 16:45:53 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1274805953.87.0.598910210962.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I'll provide a new version shortly, targeted for the py3k branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Tue May 25 18:49:08 2010
From: report at bugs.python.org (Colin Hawkett)
Date: Tue, 25 May 2010 16:49:08 +0000
Subject: [issue8819] variable resolution within exec() incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>


New submission from Colin Hawkett <hawkett at gmail.com>:

A discussion on stack overflow - http://stackoverflow.com/questions/2904274/globals-and-locals-in-python-exec - has led to the conclusion that the variable lookup behaviour within code run using exec() is not behaving as expected. Variable lookup inside a class definition does not search the enclosing scope's locals() prior to issuing a NameError - there are full details and test cases at the above URL.

----------
components: None
messages: 106447
nosy: hawkett
priority: normal
severity: normal
status: open
title: variable resolution within exec() incorrect
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8819>
_______________________________________

From report at bugs.python.org  Tue May 25 18:53:56 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 16:53:56 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274806436.49.0.402113211118.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Great, thanks.

However urlsplit and urlparse still take what one would expect to be recognized as the netloc and assigns it to the 'path' key.  If that is by design perhaps we should at least warn people?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 18:55:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 May 2010 16:55:56 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1274806556.96.0.415488579797.issue7511@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue May 25 18:55:57 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 16:55:57 +0000
Subject: [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1274806557.49.0.494685632834.issue8653@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

The default_scheme issue I brought up has been fixed in #8818

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8653>
_______________________________________

From report at bugs.python.org  Tue May 25 19:15:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 17:15:18 +0000
Subject: [issue8819] variable resolution within exec() incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274807718.72.0.124950582708.issue8819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This looks like a duplicate of issue 991196.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8819>
_______________________________________

From report at bugs.python.org  Tue May 25 19:20:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 17:20:46 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1274808046.05.0.271103074909.issue6641@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue May 25 19:33:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 17:33:01 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274808781.61.0.211580216214.issue8818@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've added Senthil as nosy to double check me, but my understanding is that the scheme is just the part up to the colon.  If you want to have a netloc in the URL, you have to precede it with a '//'.  Otherwise there's no netloc.

----------
assignee: docs at python -> 
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 19:41:54 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 17:41:54 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274809314.18.0.171067848435.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Ok, you're right:

>>> urlsplit('cnn.com')
SplitResult(scheme='', netloc='', path='cnn.com', query='', fragment='')
>>> urlsplit('//cnn.com')
SplitResult(scheme='', netloc='cnn.com', path='', query='', fragment='')
>>> 

Although I see that nowhere in the documentation.  It seems to me that in the scenario most people are dealing with, where they are getting 'cnn.com' or 'http://cnn.com' but don't know which ahead of time, this will be useless.  I don't see who would ever have '//cnn.com' without constructing that string specifically for urlsplit.

I would propose that '/whatever' becomes the path because it starts with slash, otherwise, it becomes the netloc and everything after the first slash becomes the path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 19:45:18 2010
From: report at bugs.python.org (jan matejek)
Date: Tue, 25 May 2010 17:45:18 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1274809518.25.0.884462058132.issue8335@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

yes, reverting r72637 fixes this problem for me

it reintroduces the original bug (there is some temporary file left behind), but i don't care about that

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8335>
_______________________________________

From report at bugs.python.org  Tue May 25 19:53:26 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 25 May 2010 17:53:26 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274809314.18.0.171067848435.issue8818@psf.upfronthosting.co.za>
Message-ID: <AANLkTikSEnDuwp3WH4wWMJ76bCptrApdFTR6M3vlTVQh@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Tue, May 25, 2010 at 1:41 PM, AdamN <report at bugs.python.org> wrote:
> Although I see that nowhere in the documentation.

It needn't be in the urlparse documentation; the RFCs on URL syntax
apply here.  None of what's going on with the urlparse module is
Python specific, as far as the URL interpretation is concerned.

>?It seems to me that in the scenario most people are dealing with, where
> they are getting 'cnn.com' or 'http://cnn.com' but don't know which ahead
> of time, this will be useless. ?I don't see who would ever have '//cnn.com'
> without constructing that string specifically for urlsplit.

'cnn.com' isn't a URL, and there's no need for urlparse to handle it
direectly.  That just complicates things.

Doing something above and beyond what the RFCs specify means you need
to really think about the heuristics you're applying.  If there's a
useful set of heuristics that folks can agree on, that's a good case
for a new module distributed on PyPI.

  -Fred

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 20:04:40 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 18:04:40 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274810680.56.0.771700938441.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I appreciate what you're saying but nobody, I guarantee nobody, is using the '//cnn.com' semantics.

Anyway, in RFC 3986 in the Syntax Components section, you'll see that the '://' is not part of scheme or netloc.  I could imagine urlsplit() failing if the url was not prepended by '//' or 'scheme://', but why would being prepended with nothing cause urlsplit() to presume it's a path?

Can we at least document this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 20:07:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 May 2010 18:07:37 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1274810857.55.0.468318652915.issue6312@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks Senthil!

----------
versions: +Python 3.1, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Tue May 25 20:16:07 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 25 May 2010 18:16:07 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274810680.56.0.771700938441.issue8818@psf.upfronthosting.co.za>
Message-ID: <AANLkTineEPaLMV6vH1QLbKKnqQBtilx4LXcmXAvsbAx9@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

The module is documented as supporting "Relative Uniform Resource
Locators", in which a value with a non-rooted path is supported using
simply "non/rooted/path".

See the third paragraph in the Python 2.6 documentation, starting "The
module has been designed".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 20:17:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 May 2010 18:17:27 +0000
Subject: [issue7844] Add -3 warning for absolute imports.
In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>
Message-ID: <1274811447.31.0.450892219816.issue7844@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Benjamin, are we still in time for this if someone provides a patch?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7844>
_______________________________________

From report at bugs.python.org  Tue May 25 20:21:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 May 2010 18:21:47 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1274811707.33.0.554186430557.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My review of 4Suite?s config command is on <http://bitbucket.org/Merwok/distutils2/wiki/4suite/config>. Comments welcome.

(Adding my mentor to the nosy list.)

----------
keywords: +gsoc
nosy: +titus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Tue May 25 20:26:16 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 18:26:16 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274811976.7.0.294620734563.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I think I misspoke before.  What I'm referring to is when somebody uses the 'scheme' parameter:

urlsplit('cnn.com',scheme='http')

Is there no way that we can document that this won't work the way that people think it will?  Is it really reasonable for a high-level language to expect people to have read a 100 page RFC in order to know that regular expressions will have to be used for this type of situation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 20:30:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 18:30:45 +0000
Subject: [issue8817] Expose round-to-nearest division algorithm in
	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274812245.07.0.964217134735.issue8817@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for reviewing!

Updated patch, that addresses points 1-3.  For 4, there's no need for the old code, since "self - divmod_near(self, 10**-n)[1]" is enough.  And I didn't like the old algorithm anyway;  the new one is more straightforward.  For 5, I've added a Python version of divmod_near to the comments.

----------
Added file: http://bugs.python.org/file17462/div_nearest2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8817>
_______________________________________

From report at bugs.python.org  Tue May 25 20:42:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 18:42:00 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274812920.28.0.329238711356.issue8818@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How would you expect urlsplit to differentiate between a relative path and a path with a netloc?  I would think that most people would expect the semantics the module provides without reading any additional documentation.  I certainly did, to the point where when reading your example I didn't even notice that there was any problem report other than the misnaming of the scheme keyword :)

You could suggest a clarification to the docs if you like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 20:53:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 18:53:04 +0000
Subject: [issue8819] variable resolution within exec() incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274813584.46.0.220642864577.issue8819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Judging by the issue 991196 discussion, the described behaviour is intentional.  In particular, this behaviour isn't likely to change in Python 2.x:  2.6 is in bugfix only mode, and 2.7 is too close to release to start messing with internals.

You may be able to make an argument that the behaviour should be changed in Python 3.x; that discussion should happen on python-dev or python-ideas rather than on the tracker, though.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> An inconsistency with nested scopes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8819>
_______________________________________

From report at bugs.python.org  Tue May 25 21:03:40 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 19:03:40 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274814220.77.0.00373456358677.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I would say right under:

urlparse.urlparse(urlstring[, default_scheme[, allow_fragments]])?

Put:

urlstring is a pseudo-url.  If the string has a scheme, it will be interpreted as a scheme, followed by a path, querystring and fragment.  If it is prepended with a double-slash '//', it will be interpreted as a netloc followed by a path, querystring and fragment.  Otherwise, it will be interpreted as a path followed by a querystring and fragment.

I'm still confused about when anybody would use a relative path with a default scheme and no netloc but I'll leave that decision to you guys.  

Thanks,
Adam

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 21:07:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 19:07:25 +0000
Subject: [issue8816] Add test cases for builtins
In-Reply-To: <1274752032.87.0.724423132707.issue8816@psf.upfronthosting.co.za>
Message-ID: <1274814445.07.0.742721670951.issue8816@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied patches (minus the duplicate trunk tests for range, and minus some trailing whitespace) in r81525 (trunk) and r81526 (py3k).  Thanks!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8816>
_______________________________________

From report at bugs.python.org  Tue May 25 21:08:42 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 25 May 2010 19:08:42 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1274814522.71.0.692240957301.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree with all points. Could you fix it directly if at all possible?
Of course eventually I'd do it, it might take some time until I get
around to it though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue May 25 21:09:42 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 25 May 2010 19:09:42 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274814220.77.0.00373456358677.issue8818@psf.upfronthosting.co.za>
Message-ID: <AANLkTikGdat3qGrNjip84ygyzDjNjQ179qtOVRlO9df5@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Tue, May 25, 2010 at 3:03 PM, AdamN <report at bugs.python.org> wrote:
> I'm still confused about when anybody would use a relative path with a default scheme and no netloc but I'll leave that decision to you guys.

The strings are not pseudo-URLs, they're relative references, as documented.

This is used all the time in HREF and SRC attributes in web pages,
which is exactly the use case for urlparse.urljoin().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8818>
_______________________________________

From report at bugs.python.org  Tue May 25 21:24:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 25 May 2010 19:24:46 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1274785630.14.0.304446803384.issue5689@psf.upfronthosting.co.za>
Message-ID: <4BFC23FB.6080109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> For other alternatives to the LGPL liblzma, you really don't have
> any,

If that's really the case (which I don't believe it is), then this
project stops right here. If the underlying library is LGPL, it would
require us to distribute its sources along with the Windows binaries,
which I'm not willing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Tue May 25 21:42:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 19:42:38 +0000
Subject: [issue8636] enumerate() test cases do not cover optional start
	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1274816558.15.0.692509145638.issue8636@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks like there's still a bit of brokenness here:  when I run test_enumerate by itself:

./python.exe Lib/test/test_enumerate.py

I get the following:

Traceback (most recent call last):
  File "Lib/test/test_enumerate.py", line 253, in <module>
    test_main(verbose=True)
  File "Lib/test/test_enumerate.py", line 248, in test_main
    test_support.run_unittest(*testclasses)
NameError: global name 'testclasses' is not defined
[76533 refs]

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8636>
_______________________________________

From report at bugs.python.org  Tue May 25 21:48:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 May 2010 19:48:50 +0000
Subject: [issue8636] enumerate() test cases do not cover optional start
	argument
In-Reply-To: <1273153699.94.0.112049339171.issue8636@psf.upfronthosting.co.za>
Message-ID: <1274816930.03.0.821741072658.issue8636@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

NameError fixed in r81527 through r81530.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8636>
_______________________________________

From report at bugs.python.org  Tue May 25 22:14:32 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 25 May 2010 20:14:32 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1274818472.45.0.219975066079.issue8335@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Dylan, what is your platform ?

The only difference is that the test chdir in a new temporary directory.

Could anyone trace the test to step into the linker call to see its error output ? (can't reproduce here)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8335>
_______________________________________

From report at bugs.python.org  Tue May 25 22:26:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 20:26:48 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1274819208.04.0.196662943871.issue665194@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665194>
_______________________________________

From report at bugs.python.org  Tue May 25 22:37:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 20:37:19 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1274819839.45.0.31683868228.issue6641@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

If concrete tzinfo subclass is added to datetime module (see issue5094), it will become feasible to meaningfully parse timezone information.

----------
assignee:  -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue May 25 22:55:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2010 20:55:22 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1274820922.71.0.0886987160071.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

asvetlov> I'm skeptical about surrogates particularly for that 
asvetlov> problem. From my perspective the solution is only to use 
asvetlov> native unicode support for windows file operation functions.

It's not exclusive. We can use surrogates on POSIX and then convert to bytes at the system calls, and use the unicode version of the Windows API. In both cases, filenames are unicode.

asvetlov> Conversions utf-8 -> mbcs -> utf8 will loose encoding
asvetlov> information thanks to tricky Microsoft mbcs encoding schema.
asvetlov> If I'm wrong please correct me.

On Windows, Python3 *does* convert unicode to bytes with the mbcs encoding in the import machinery. I tested and Python3 has the same problem on Windows with non decodable filenames than Python3 on Unix. Eg. add "\u0809" character (random non encodable character) to the Python directory name: Python3 doesn't start if the code page cannot encode/decode it.

To fix all OS (Windows and POSIX), Python3 import machinery should not convert filenames to bytes but manipulate unicode characters and only convert filenames to bytes on POSIX at the last moment (at system calls).

--

mbcs codec ignores the error handler: it replaces unknown characters by "?" by default, see #850997.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Tue May 25 22:56:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 May 2010 20:56:32 +0000
Subject: [issue7844] Add -3 warning for absolute imports.
In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>
Message-ID: <1274820992.06.0.272342939132.issue7844@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, if soonish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7844>
_______________________________________

From report at bugs.python.org  Tue May 25 23:14:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 21:14:53 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1274756800.67.0.166523412485.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTinrZFf-3GRjhZ1cByN1Jp14X-yPzMXB9kgLBdIF@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan <report at bugs.python.org> wrote:
..
> I had originally thought of doing the class, and then having constants associated with it:
>
> ?UTC.UTC0
>
> Eventually if we support multiple timezones:
>
> ?UTC.UTC1
..
>
> Well... maybe not given how impossible the naming would be.
..

I actually like your original idea.  It seems wasteful to create a
concrete timezone class in a C module and only use it for a single
timezone.  FixedOffset class in tzinfo-examples.py is only slightly
more complicated than UTC class and as explained in the comment above
it, "FixedOffset(0, "UTC") is a different way to build a UTC tzinfo
object.  FixedOffset objects can then be used to produce aware
datetime instances from strptime.  (See issue6641.)  I would only
define utc = FixedOffset(0, "UTC") instance and make name argument to
FixedOffset optional defaulting to UTC(+/-)hhmm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 23:20:30 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 May 2010 21:20:30 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1274822430.78.0.775040651315.issue6641@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue May 25 23:33:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2010 21:33:25 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1274823205.39.0.630430824271.issue4769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited base64_main.patch (+ tests): 3.2 (r81533) and 3.1 (r81534).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Tue May 25 23:35:14 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 May 2010 21:35:14 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274823314.68.0.978113071512.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The singleton dislike from Antoine and me is that they are generally just not liked in the stdlib. None/True/False are special cases because they are syntax, so having ``None is None`` ever not work would just be weird. Otherwise singletons are unnecessary in Python. Just look through the stdlib and you will find very few singletons as they are generally considered bad. Having to write a custom __eq__ or __hash__ is just part of being explicit. And trying to make a factory function that always returns the same instance is not a solution either. I understand pytz might use them, but this is the stdlib, so we need to go with what we consider best practice for Python since it will lead to much more use than pytz gets.

Now if a simple FixedOffsetTimeZone class was added and we just pre-populated the datetime module with a utc attribute that contained an instance of that class set to the proper values for UTC, that I could support without controversy. That would get you your "singleton" by reliably using the same instance without having to try to hack in singleton support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 23:43:29 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 May 2010 21:43:29 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274823809.03.0.626691979488.issue8796@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That deprecation is way too fast. If someone wants to write code that works in Python 2.5 or older *and* Python 3 then codecs.open will most likely be how they keep compatibility for reading in encoded files.

But yes, overall it should get deprecated. Probably a PendingDeprecationWarning to start is good and then eventually switch to a DeprecationWarning once most Linux distributions have moved to Python 2.6.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 25 23:45:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2010 21:45:24 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274823924.35.0.0450761806726.issue8796@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If someone wants to write code that works in Python 2.5 
> or older *and* Python 3 then codecs.open will most likely
> be how they keep compatibility for reading in encoded files.

Can't 2to3 do the conversion? (codecs.open => open)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 25 23:49:59 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 May 2010 21:49:59 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1274824199.69.0.0657400115395.issue8796@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm not talking about those people who use 2to3, I'm talking about those who want source-compatibility between Python 2 and Python 3. So they don't run 2to3 as it just works in Python 3 without modification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 25 23:51:55 2010
From: report at bugs.python.org (Koen van de Sande)
Date: Tue, 25 May 2010 21:51:55 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274824315.48.0.161987069458.issue5689@psf.upfronthosting.co.za>


Koen van de Sande <koen at tibed.net> added the comment:

The XZ Utils website ( http://tukaani.org/xz/ ) states the following:

"The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts. 

Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3."

So, liblzma is not the problem. But the license of PylibLZMA is LGPL3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Tue May 25 23:55:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 21:55:47 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1274823314.68.0.978113071512.issue5094@psf.upfronthosting.co.za>
Message-ID: <AANLkTim6Fxls94r92RFUynbTzOKRpRIzwQZ8SYNh8i6G@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

..
Thanks for the explanation.  I realize that I should not have used the
s-word. :-)  In fact I only wanted a module level constant utc = UTC()
and did not care much about other UTC class instances and whether any
are permitted or easy to create.

Well, the datetime module is not exactly the place you want to start
if you want to lead anyone to best Python practices. :-) (Just think
of datetime subclassing from date!)

> Now if a simple FixedOffsetTimeZone class was added and we just pre-populated the datetime module with a utc attribute that contained an
> instance of that class set to the proper values for UTC, that I could support without controversy.

This is exactly my preferred solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 23:58:49 2010
From: report at bugs.python.org (Rafe Kaplan)
Date: Tue, 25 May 2010 21:58:49 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274824729.54.0.0866350092875.issue5094@psf.upfronthosting.co.za>


Rafe Kaplan <rafek at google.com> added the comment:

"Note that I am not suggesting passing anything to utcnow().  I would
either leave it unchanged or make it always return aware datetime
instances."

FYI, all other issues aside, having utcnow() (with no parameters) return a tzaware instance will introduce backward compatibility problems.  As it is, users are not expecting utcnow to return a date-time with any tzinfo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Tue May 25 23:59:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 21:59:08 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274824748.12.0.741476459831.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Roundup bug bites again.  Reposting via web:

-----
On Tue, May 25, 2010 at 5:35 PM, Brett Cannon <report at bugs.python.org> wrote:
>
> The singleton dislike from Antoine and me is that they are generally just not liked in the stdlib.
..
Thanks for the explanation.  I realize that I should not have used the
s-word. :-)  In fact I only wanted a module level constant utc = UTC()
and did not care much about other UTC class instances and whether any
are permitted or easy to create.

> .. so we need to go with what we consider best practice for Python since it will lead to much more use than pytz gets.
>
Well, the datetime module is not exactly the place you want to start
if you want to lead anyone to best Python practices. :-) (Just think
of datetime subclassing from date!)

> Now if a simple FixedOffsetTimeZone class was added and we just pre-populated the datetime module with a utc attribute that contained an
> instance of that class set to the proper values for UTC, that I could support without controversy.

This is exactly my preferred solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 00:08:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2010 22:08:57 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1274825337.1.0.0200741033018.issue4769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Accept unicode string is not "pure", but I agree that it's convinient. Here is a patch:
 * base64.b(16|32|64)encode and b64.encodebytes accept unicode string
 * unicode is first encoded to utf-8 to get a byte string
 * Update the docstrings and the documentation
 * Fix tests

----------
Added file: http://bugs.python.org/file17463/base64_str.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Wed May 26 00:14:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 22:14:34 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274825674.46.0.797822552753.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that Brett has already mentioned backward compatibility issues, but suggested that "[adding tz_aware argument may provide] a transition plan to make utcnow() always return a timezone-aware datetime object." [msg106413]

I would say, lets leave utcnow() alone.  It is ugly enough without a boolean argument.  I don't see how datetime.now(utc) can be too error prone.  I think Brett's comment about a stupid developer was about passing tzinfo instead of bool to utcnow() and that I agree makes no sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 00:19:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2010 22:19:55 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1274823205.39.0.630430824271.issue4769@psf.upfronthosting.co.za>
Message-ID: <201005260019.48093.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I commited base64_main.patch (+ tests): 3.2 (r81533) and 3.1 (r81534).

Hum, the test fails on Windows: fixed by r81535 (3.2) and r81536 (3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Wed May 26 00:40:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2010 22:40:57 +0000
Subject: [issue3798] SystemExit incorrectly displays unicode message
In-Reply-To: <1220737862.32.0.22799945135.issue3798@psf.upfronthosting.co.za>
Message-ID: <1274827257.41.0.481725953776.issue3798@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to 2.7 (r81537) and 2.6 (r81539), blocked in 3.2 (r81538: py3k was already fixed by r81252).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3798>
_______________________________________

From report at bugs.python.org  Wed May 26 00:42:43 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 May 2010 22:42:43 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274827363.82.0.181139770917.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If we don't modify utcnow (and similar UTC methods) to take a flag saying to use the utc instance, then the methods should at least get deprecated with a message saying that people should be using ``now(utc)``, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 01:11:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 23:11:40 +0000
Subject: [issue8817] Expose round-to-nearest division algorithm in
	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274829100.7.0.687427924163.issue8817@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Looking at

    Py_DECREF(one);
 
    result = PyTuple_New(2);
    if (result == NULL)
        goto error;
..
  error:
    Py_XDECREF(one);


If PyTuple_New fails, wouldn't it result in one being DECREF's twice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8817>
_______________________________________

From report at bugs.python.org  Wed May 26 01:24:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 25 May 2010 23:24:00 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1274829840.12.0.111638332903.issue6378@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
type: behavior -> feature request
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Wed May 26 01:28:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 23:28:55 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274830135.97.0.849245223147.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching a new patch with documentation changes, additional tests, updated issue8817 patch and a reference leak fix.

----------
Added file: http://bugs.python.org/file17464/issue1289118+issue8817-withdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Wed May 26 01:44:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 23:44:32 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274831072.99.0.797476666772.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Brett: "[utcnow] should at least get deprecated with a message saying that people should be using ``now(utc)``"

Yes, I believe all utcxxx methods of datetime are a kludge due to the lack of concrete UTC tzinfo:

utcfromtimestamp() -> fromtimestamp(utc)
t.utctimetuple() -> t.replace(tzinfo=utc).timetuple()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 01:49:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 23:49:55 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1274831395.78.0.901391762066.issue5023@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Wed May 26 01:52:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 23:52:50 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1274831570.88.0.424844608261.issue7584@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed May 26 01:55:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 25 May 2010 23:55:45 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1274831745.87.0.823533078391.issue1100942@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed May 26 02:16:35 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 May 2010 00:16:35 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274832995.86.0.151068108933.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, it looks like we are reaching consensus here on several points:

1. Implement FixedOffsetTimezone
2. Provide a utc attribute on the datetime module that is set to ``FixedOffsetTimezone(0, "UTC")``
3. Deprecate the various utc* methods with messages pointing out how to use the new utc instance instead of the method

If this seems reasonable, then I see two questions to answer.

First is how long to do the deprecations. I say remove in Python 3.5. Existing for three versions is six more years of usage from the time of 3.2's release to that of 3.6. Plus it is easy to be backwards-compatible by showing in the docs how to create one's own UTC class.

The second is whether we should take this opportunity to fix datetime being a C extension module exclusively. I know PyPy has their own pure Python version of datetime that they plan to eventually contribute. We might as well use this as the chance to create Lib/datetime.py and have that conditionally import _datetimemodule.c (see the heapq module on how to handle this kind of situation). That way PyPy can eventually just drop their code into datetime.py. Biggest issue will be extension modules wanting to use the C extension API, but since this is new stuff it shouldn't affect them except for the module renaming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 02:22:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 00:22:24 +0000
Subject: [issue5434] datetime.monthdelta
In-Reply-To: <1236402290.49.0.02662803662.issue5434@psf.upfronthosting.co.za>
Message-ID: <1274833344.66.0.233846186721.issue5434@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

MonthDelta has been published on PyPI and there was no activity on this issue since then. I conclude that there is little support for including this in stdlib.  I am marking this as "rejected" and setting the status to pending.  I will close this issue in a few weeks unless I hear objections. 

Jess,

I see that your package is healthy on PyPI with over 700 downloads for the latest version.  Note that some additional operations have been added recently to timedelta object and more are in the works.  You may want to consider adding them to the next version of your package.  (See issue 1289118 and issue 2706.)

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5434>
_______________________________________

From report at bugs.python.org  Wed May 26 02:39:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 00:39:24 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274834364.0.0.183741444861.issue5094@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have no opinion on the first question.  I would be fine with a simple "soft" deprecation where we simply add a note in documentation warning that these methods create naive datetime instances and it is preferable to use aware variants produced by meth(utc).  On the other hand eventually removing these methods will make maintenance easier.  Sorry I cannot offer more help with this decision.

With respect to the second question, I would be against mixed C/Python implementation.  I would also like to see C API to the new concrete tzinfo  classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 02:47:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 00:47:03 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1274834823.01.0.652871487034.issue5516@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am leaning towards "won't fix".  Any objections?

----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed May 26 02:48:43 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 May 2010 00:48:43 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274834923.96.0.251016972239.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The stated long-term goal of the stdlib is to minimize the C extension modules to only those that have to be written in C (modules can still have performance enhancing extension back-ends). Since datetime does not meet that requirement it's not a matter of "if" but "when" datetime will get a pure Python version and use the extension code only for performance.

If someone wants to implement the C code for a tzinfo concrete class that we are talking about, that's fine. But that will not prevent datetime from getting a pure Python version at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 02:52:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 00:52:58 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1274835178.96.0.442874165884.issue8005@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Any objections to closing this as "won't fix"?

----------
nosy: +belopolsky -Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Wed May 26 02:55:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 00:55:33 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1274835333.33.0.0264999789157.issue7150@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Wed May 26 02:57:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 00:57:37 +0000
Subject: [issue5476] datetime: timedelta(minutes = i) silently fails with
	numpy.int32 input
In-Reply-To: <1236786647.39.0.745171492116.issue5476@psf.upfronthosting.co.za>
Message-ID: <1274835457.91.0.835045337628.issue5476@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5476>
_______________________________________

From report at bugs.python.org  Wed May 26 03:00:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 01:00:37 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1274835637.5.0.517883899932.issue1647654@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647654>
_______________________________________

From report at bugs.python.org  Wed May 26 03:04:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 01:04:34 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1274835874.58.0.923776664498.issue1667546@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667546>
_______________________________________

From report at bugs.python.org  Wed May 26 03:05:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 01:05:41 +0000
Subject: [issue1667546] Time zone-capable variant of time.localtime
Message-ID: <1274835941.04.0.835873405434.issue1667546@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1667546>
_______________________________________

From report at bugs.python.org  Wed May 26 03:18:39 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 26 May 2010 01:18:39 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1274836719.64.0.570349283954.issue8005@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

None here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Wed May 26 03:47:45 2010
From: report at bugs.python.org (Jess Austin)
Date: Wed, 26 May 2010 01:47:45 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1274838465.59.0.244491275756.issue5516@psf.upfronthosting.co.za>


Jess Austin <jess.austin at gmail.com> added the comment:

Could you provide some reasoning for such a resolution?  I had thought that "won't fix" indicated that the issue wasn't actually an error in behavior.

I grant that most people will never see this particular error, but it is an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed May 26 04:07:51 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 May 2010 02:07:51 +0000
Subject: [issue6507] Enhance dis.dis to autocompile codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1274839671.78.0.296029578166.issue6507@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Missed the window for 2.7, but should be right for 3.2.

There's a minor error in the documentation (strings need to be mentioned in the list of acceptable types), but I can fix that on commit.

----------
assignee: benjamin.peterson -> ncoghlan
priority: low -> normal
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________

From report at bugs.python.org  Wed May 26 04:19:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 02:19:09 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1274840349.37.0.402621547751.issue5516@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Could you provide some reasoning for such a resolution? 
> I had thought that "won't fix" indicated that the issue
> wasn't actually an error in behavior.

No, that would be "invalid."  IMO, "won't fix" is for bugs were cost of fixing them outweighs the benefits.  Here is a typical example: issue8309 "Sin(x) is Wrong".

Here, however I am torn between "won't fix" and "invalid."  As I said in my previous comment:

"""
Note, however that the problematic behavior is due to D/DT
classes implementor's choice not to derive DT from D.  Whether
resulting violation of the symmetry of equality is a bug in python or
D/DT implementation is at least an open question.
"""

I don't mind keeping this open if there is a hope that someone will come up with a working solution.  The current patch is not a solution.

----------
priority: normal -> low
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed May 26 04:25:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 02:25:22 +0000
Subject: [issue8005] datetime's comparison methods do not return
	NotImplemented when they should
In-Reply-To: <1266960457.45.0.360868730978.issue8005@psf.upfronthosting.co.za>
Message-ID: <1274840722.33.0.819675423859.issue8005@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8005>
_______________________________________

From report at bugs.python.org  Wed May 26 04:48:04 2010
From: report at bugs.python.org (Joseph)
Date: Wed, 26 May 2010 02:48:04 +0000
Subject: [issue8820] IDLE not launching correctly
In-Reply-To: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>
Message-ID: <1274842084.45.0.257196773636.issue8820@psf.upfronthosting.co.za>


New submission from Joseph <joseph.a.marlin at gmail.com>:

I am on Windows 7 64 bit. Issue occurs trying to open IDLE or Module Docs.

My problem is very similar to this one: http://bugs.python.org/issue8247
Also, it is almost identical to this: http://bugs.python.org/issue7265

Followed the directions in issue 7265, here is the error message. 


c:\Python26>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 6, in <module>
    import PyShell
  File "c:\Python26\Lib\idlelib\PyShell.py", line 14, in <module>
    import macosxSupport
  File "c:\Python26\Lib\idlelib\macosxSupport.py", line 6, in <module>
    import Tkinter
  File "c:\Python26\lib\lib-tk\Tkinter.py", line 38, in <module>
    import FixTk
  File "c:\Python26\lib\lib-tk\FixTk.py", line 63, in <module>
    import _tkinter
ImportError: DLL load failed: %1 is not a valid Win32 application.


Note that I am definitely running Windows 64 bit, and I definitely downloaded the 64 bit version of Python. Also, I did not apply the fix that worked in 7265 because first of all, that wasn't the issue, (here I can't import tkinter, there he couldn't open a file), and secondly, I don't have the file he mentioned that he unhid.

----------
components: IDLE
messages: 106504
nosy: NightFalcon
priority: normal
severity: normal
status: open
title: IDLE not launching correctly
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8820>
_______________________________________

From report at bugs.python.org  Wed May 26 05:27:21 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 May 2010 03:27:21 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1274844441.94.0.365878807682.issue5516@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd suggest leaving it open - the current situation is definitely suboptimal, but it is likely to take some close scrutiny to get it to behave nicely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed May 26 06:11:53 2010
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 26 May 2010 04:11:53 +0000
Subject: [issue8821] Range check on unicode repr
In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>
Message-ID: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

In unicodeobject.c's unicodeescape_string, in UCS2 builds, if the last character of the string is the start of a UTF-16 surrogate pair (between '\ud800' and '\udfff'), there is a slight overrun problem. For example:

>>> repr(u'abcd\ud800')

Upon reading ch = 0xd800, the test (ch >= 0xD800 && ch < 0xDC00) succeeds, and it then reads ch2 = *s++. Note that preceding this line, s points at one character past the end of the string, so the value read will be garbage. I imagine that unless it falls on a segment boundary, the worst that could happen is the character '\ud800' is interpreted as some other wide character. Nevertheless, this is bad.

Note that *technically* this is never bad, because _PyUnicode_New allocates an extra character and sets it to '\u0000', and thus the above example will always set ch2 to 0, and it will behave correctly. But this is a tenuous thing to rely on, especially given the comment above _PyUnicode_New:

/* We allocate one more byte to make sure the string is
   Ux0000 terminated -- XXX is this needed ?
*/

I thought about removing that XXX, but I'd rather fix the problem. Therefore, I have attached a patch which does a range check before reading ch2:

--- Objects/unicodeobject.c	(revision 81539)
+++ Objects/unicodeobject.c	(working copy)
@@ -3065,7 +3065,7 @@
         }
 #else
         /* Map UTF-16 surrogate pairs to '\U00xxxxxx' */
-        else if (ch >= 0xD800 && ch < 0xDC00) {
+        else if (ch >= 0xD800 && ch < 0xDC00 && size > 0) {
             Py_UNICODE ch2;
             Py_UCS4 ucs;

Also affects Python 3.

----------
components: Unicode
files: unicode-range-check.patch
keywords: patch
messages: 106506
nosy: mgiuca
priority: normal
severity: normal
status: open
title: Range check on unicode repr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17465/unicode-range-check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8821>
_______________________________________

From report at bugs.python.org  Wed May 26 06:26:17 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 26 May 2010 04:26:17 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1274847977.83.0.0635961808567.issue5516@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Date and Datetime comparison is not defined and not documented, and until we find a nice way to implement the comparison, we should just let this comparison raise NotImpelemented.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed May 26 06:55:06 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 26 May 2010 04:55:06 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274849706.51.0.597895775035.issue6715@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 06:56:56 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 May 2010 04:56:56 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1274849816.42.0.0172210657459.issue5516@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Deprecating the feature for 3.x is certainly an option. May be a little drastic though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Wed May 26 07:03:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 05:03:12 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1274850192.49.0.361624453978.issue7150@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've untabified my last patch and added a NEWS entry.  I believe it is ready for commit review.  Mark?

----------
nosy: +mark.dickinson
stage: patch review -> commit review
Added file: http://bugs.python.org/file17466/issue7150a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Wed May 26 07:10:15 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 26 May 2010 05:10:15 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274850615.63.0.474073598868.issue5689@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed May 26 09:10:00 2010
From: report at bugs.python.org (Colin Hawkett)
Date: Wed, 26 May 2010 07:10:00 +0000
Subject: [issue8819] variable resolution within exec() incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274857800.24.0.820502841965.issue8819@psf.upfronthosting.co.za>


Colin Hawkett <hawkett at gmail.com> added the comment:

Agreed, this is the same issue. I'll make my argument that this is a bug (intentional or otherwise) on that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8819>
_______________________________________

From report at bugs.python.org  Wed May 26 09:28:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 07:28:39 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1274858919.04.0.62987634713.issue7150@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take a look at this patch later today.

----------
assignee: belopolsky -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Wed May 26 09:47:36 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 May 2010 07:47:36 +0000
Subject: [issue4810] timeit needs "official" '--' flag
In-Reply-To: <18782.17333.839740.4416@montanaro-dyndns-org.local>
Message-ID: <1274860056.19.0.0599241030706.issue4810@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This "--" trick is implemented by the getopt module.
OTOH on my system, 'grep' also recognizes this, and I could not find any documentation about it, neither with "grep --help" nor "man grep".

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4810>
_______________________________________

From report at bugs.python.org  Wed May 26 09:52:55 2010
From: report at bugs.python.org (Colin Hawkett)
Date: Wed, 26 May 2010 07:52:55 +0000
Subject: [issue991196] An inconsistency with nested scopes
Message-ID: <1274860375.56.0.439369632991.issue991196@psf.upfronthosting.co.za>


Colin Hawkett <hawkett at gmail.com> added the comment:

#8819 was closed as duplicate. That issue linked a description of the problem on stack overflow http://stackoverflow.com/questions/2904274/globals-and-locals-in-python-exec. I would like to argue that this is a bug, and should be fixed in 2.6+. The definition of bug here is that python does not behave as documented - that variable name resolution does *not* check the locals() of the enclosing scope. The fact that the code mistakenly assumes locals and globals would be the same thing in this situation does not mean it is not a bug.

The statement in the previous comment - 'if you want exec to mimc the top level environment, you need to pass it a single dictionary' is true, but it hides that fact that this is the *only* thing you can do - if you *don't* want exec to mimic the top level environment, what's the approach? Doing anything else just creates a unique, undocumented, oddly behaving scope that doesn't apply closures correctly.

What are the use cases for passing in locals? Doing so means your code behaves abnormally, unless you think carefully about how you write it, and that's not good - 'Write python code like this, except for this situation where it doesn't work, and you have to write your python like this, avoiding certain closure scenarios that would otherwise work.' What's the exec() API with locals for?

If you don't pass in locals, or make globals and locals the same dictionary, then its an absolute pain to retrieve the definitions created in the exec'd code - they're mixed in with all the globals python adds, and if you don't know in advance what is being defined in the code block, it's close to impossible. To me, this is the primary use case for locals being passed in, and was surely the intention when the API was constructed.  This bug prevents this use case.

I'm guessing that somewhere in the python source there is some code that  goes (pseudo)

if scope == module: check_globals()
else:
  check_locals()
  check_globals()

and that this is done for performance reasons, but surely the check could be different without giving up much, and fix the problem?

if locals() is globals(): check_globals()
else:
  check_locals()
  check_globals()

----------
nosy: +hawkett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue991196>
_______________________________________

From report at bugs.python.org  Wed May 26 10:28:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 08:28:16 +0000
Subject: [issue8817] Expose round-to-nearest division algorithm in
	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274862496.23.0.0105073537891.issue8817@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, good point.  I knew there was a reason I didn't like Py_XDECREF.
I'll fix this and then apply this patch tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8817>
_______________________________________

From report at bugs.python.org  Wed May 26 10:41:49 2010
From: report at bugs.python.org (Colin Hawkett)
Date: Wed, 26 May 2010 08:41:49 +0000
Subject: [issue8819] variable resolution within exec() incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274863309.26.0.890766502146.issue8819@psf.upfronthosting.co.za>


Colin Hawkett <hawkett at gmail.com> added the comment:

Apologies for raising it in the tracker against your advice. My thinking was that you were suggesting discussions about 3.x content shouldn't be in the tracker, and I wanted to argue that it is a bug and should be fixed in 2.6+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8819>
_______________________________________

From report at bugs.python.org  Wed May 26 10:49:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 08:49:52 +0000
Subject: [issue8819] variable resolution within exec() incorrect
In-Reply-To: <1274806148.14.0.229053975552.issue8819@psf.upfronthosting.co.za>
Message-ID: <1274863792.17.0.332799606158.issue8819@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  To get this changed in 2.x you'd have to convince people that it really is a bug.  You probably also need to do that very soon for there to be any hope of 2.7 having changed behaviour.

I'd suggest bringing this up on the python-dev mailing list;  it'll get better visibility there.  If you can describe exactly what should change (and even better, how that change might be implemented) that would be a bonus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8819>
_______________________________________

From report at bugs.python.org  Wed May 26 10:51:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 May 2010 08:51:09 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274863869.25.0.308368668911.issue5689@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If the underlying library is LGPL, it would
> require us to distribute its sources along with the Windows binaries,
> which I'm not willing to do.

Martin, this is wrong, you don't have to bundle the source *in* the object code package. Making it available on some HTTP or FTP site is sufficient.
(actually, if we don't modify the library source, we can even point at the original download site)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed May 26 10:51:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 08:51:24 +0000
Subject: [issue991196] An inconsistency with nested scopes
Message-ID: <1274863884.35.0.88129806136.issue991196@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue991196>
_______________________________________

From report at bugs.python.org  Wed May 26 11:24:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 May 2010 09:24:11 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274865851.83.0.479687226875.issue5094@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The second is whether we should take this opportunity to fix datetime
> being a C extension module exclusively. I know PyPy has their own pure
> Python version of datetime that they plan to eventually contribute. We 
> might as well use this as the chance to create Lib/datetime.py and have 
> that conditionally import _datetimemodule.c (see the heapq module on 
> how to handle this kind of situation).

Of we could let PyPy contribute their own version when they want, after all.
I think additions to the datetime API are good in themselves, and we shouldn't make them depend on some mythical refactoring of the code into a separate pure Python module ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 11:58:08 2010
From: report at bugs.python.org (Stefan)
Date: Wed, 26 May 2010 09:58:08 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1274867888.04.0.319557883855.issue1731717@psf.upfronthosting.co.za>


Stefan <s.antoni at telekom.de> added the comment:

I have exactly the same problem. Is there a thread-safe alternative to execute subprocesses in threads?

----------
nosy: +santoni

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Wed May 26 12:40:37 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 26 May 2010 10:40:37 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1274870437.77.0.0148048626209.issue6312@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

The fix in r80583 is bad. It fails to close() the response (which previously worked as expected), meaning that the connection can't be re-used.

(I ran into this because Gentoo has backported the 2.6-maint fixes to their 2.6.5 distribution.)

Shall I open a new issue, or re-open this one?

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed May 26 13:12:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 26 May 2010 11:12:49 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1274872369.24.0.51065532079.issue6312@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I am just reopening this, as per dcj's comment.

----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed May 26 13:21:15 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 26 May 2010 11:21:15 +0000
Subject: [issue8781] 32-bit wchar_t doesn't need to be unsigned to be
	usable	(I think)
In-Reply-To: <1274447945.54.0.456108066249.issue8781@psf.upfronthosting.co.za>
Message-ID: <4BFD0426.8090805@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> The problem with a signed Py_UNICODE is implicit sign extension (rather than zero extension) in some conversions, for example from "char" or "unsigned char" to "Py_UNICODE". The effects could go anywhere from incorrect results to plain crashes. Not only in our code, but in C extensions relying on the unsignedness of Py_UNICODE.

Right.

The Unicode code was written with an unsigned data type in mind (range
checks, conversions, etc.). We'd have to do some serious code review to
allow switching to a signed data type.

> Is there a way to enable those optimizations while keeping an unsigned Py_UNICODE type? It seems Py_UNICODE doesn't have to be typedef'ed to wchar_t, it can be defined to be an unsigned integer of the same width. Or would it break some part of the C standard?

The memcpy optimizations don't rely on the unsignedness of
wchar_t, so they would work just as well.

----------
title: 32-bit wchar_t doesn't need to be unsigned to be usable (I think) -> 32-bit wchar_t doesn't need to be unsigned to be usable	(I think)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8781>
_______________________________________

From report at bugs.python.org  Wed May 26 13:40:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 11:40:11 +0000
Subject: [issue991196] An inconsistency with nested scopes
Message-ID: <1274874011.28.0.0768060752351.issue991196@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm guessing that somewhere in the python source there is some code that goes [...]

Unfortunately it's not nearly that simple.  As I mentioned in my message on python-dev, the problem is that 'y' gets bound with a 'STORE_NAME' opcode, which puts 'y' into the locals dict, and then retrieved from within the function with a 'LOAD_GLOBAL' opcode, which looks in the globals dict;  hence the NameError.

So should the compiler be generating a 'LOAD_NAME' instead of a 'LOAD_GLOBAL' for this code?  I'm not really familiar with the compilation process, so I've no idea whether this makes sense, or what impact it might have on existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue991196>
_______________________________________

From report at bugs.python.org  Wed May 26 14:07:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 26 May 2010 12:07:27 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

'naive' and 'aware' are key datetime types - they need a proper definition and anchor for crossrefences. If you take a look at http://docs.python.org/library/datetime.html - the definition of distinction between them is too vague and this seeds of uncertainty grow through the rest of the doc. It is not said how to make non-naive object, how to detect if object of naive or aware. All this stuff is very important for troubleshooting datetims issues in Python projects. It needs a proper documentation.

----------
assignee: docs at python
components: Documentation
messages: 106524
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: datetime naive and aware types should have a well-defined definition that can be cross-referenced

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8822>
_______________________________________

From report at bugs.python.org  Wed May 26 15:27:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 13:27:01 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1274880421.06.0.221223031876.issue2810@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to trunk in r81517 and release26-maint in r81540.

I'll cover the 3.x stuff today and then close it out.

----------
assignee: stutzbach -> brian.curtin
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed May 26 15:44:10 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 26 May 2010 13:44:10 +0000
Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

When running urllib2 and getting a BadStatus from an http server, this error is raised:

  File "/var/www/pinax-env/pline/apps/page/models.py", line 303, in render
    content = urllib2.urlopen(self.url,timeout=10).read()
  File "/usr/lib/python2.6/urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.6/urllib2.py", line 389, in open
    response = self._open(req, data)
  File "/usr/lib/python2.6/urllib2.py", line 407, in _open
    '_open', req)
  File "/usr/lib/python2.6/urllib2.py", line 367, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.6/urllib2.py", line 1146, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.6/urllib2.py", line 1119, in do_open
    r = h.getresponse()
  File "/usr/lib/python2.6/httplib.py", line 974, in getresponse
    response.begin()
  File "/usr/lib/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.6/httplib.py", line 355, in _read_status
    raise BadStatusLine(line)
httplib.BadStatusLine

Because urllib2 doesn't catch it with this:

lines 1116-1120

try:
    h.request(req.get_method(), req.get_selector(), req.data, headers)
    r = h.getresponse()
except socket.error, err: # XXX what error?
    raise URLError(err)

It is not caught anywhere else and the call blows up unless I make a special exception for all httplib exceptions.  The specific url that blew this up is:

http://phoenix.untd.com/oasx/rqst/type=sx/rdb=8203014d740000555355533a415a2d2d2d2d2d2d2d2d2d2d0100001d494a0901000000000000/version=3/origin=uol/isp=et_cau

----------
messages: 106526
nosy: adamnelson
priority: normal
severity: normal
status: open
title: urllib2 does not catch httplib.BadStatusLine
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8823>
_______________________________________

From report at bugs.python.org  Wed May 26 15:44:34 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 26 May 2010 13:44:34 +0000
Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1274881474.68.0.416734389197.issue8823@psf.upfronthosting.co.za>


Changes by AdamN <adam at varud.com>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8823>
_______________________________________

From report at bugs.python.org  Wed May 26 15:44:47 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 26 May 2010 13:44:47 +0000
Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1274881487.8.0.00389249057672.issue8823@psf.upfronthosting.co.za>


Changes by AdamN <adam at varud.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8823>
_______________________________________

From report at bugs.python.org  Wed May 26 15:58:59 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 26 May 2010 13:58:59 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1274882339.81.0.833883337903.issue6312@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Wed May 26 16:31:46 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 26 May 2010 14:31:46 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1274884306.94.0.659192991035.issue7584@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

1. David, as an original reporter who needed this for Trac (http://trac.edgewall.org/ticket/8662) and couple of other projects I strongly for 'Z' ending by default, unless you are going to explain the full difference in documentation. Expect to answer the question "Why the timestamp is not 'Z'-ended like in Atom?"

2. "-00:00" is not semantically correct as a default either. Quoting RFC again - "If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". It is not true for naive datetime stamps that represent the fact that "the time in UTC is unknown, and the offset to UTC is unknown".

3. Daniel, thanks for yet another patch contribution for this issue. default_utcoffset seems confusing to me. If I see call like datetime.rfcformat(default_utcoffset="-00:00") - I somehow expect that default_utcoffset is used if it is impossible to determine the offset. If it is only about format of zero offset then 'zerozone' param seems more logical. If it is about substitution for unknown zone, then the proper way in datetime API would be to convert object to 'aware datetime' type with proper zone prior to calling this function. Datetime API is definitely on of the worst items in Python from the user point of view.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Wed May 26 16:46:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 14:46:47 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1274885207.89.0.973466375867.issue2810@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

test_dynamic_key fails on py3k, but not because of these changes.

RegQueryValueExW doesn't appear to work with NULL for the second parameter (valueName), although it is documented to and the ANSI version on 2.x works fine. The empty string is also documented as an acceptable parameter, so while testing it out, I hardcoded "" in PyQueryValueEx and the calls worked. With NULL, it raises "WindowsError: [Error 87] The parameter is incorrect".

Thoughts? The current py3k patch is attached.

----------
Added file: http://bugs.python.org/file17467/issue2810_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed May 26 17:02:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 15:02:41 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1274886161.76.0.375292224496.issue7150@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The patch looks good to me.  Please apply!

----------
assignee: mark.dickinson -> belopolsky
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Wed May 26 17:12:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 26 May 2010 15:12:26 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1274886746.56.0.106908071812.issue2810@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I wrote a short C program to test a few different variations.  It looks to me like a bug in the operating system's implementation of HKEY_PERFORMANCE_DATA (which is a virtual registry key).  If I pass NULL as the second parameter to a more conventional key that has a default value, everything works fine.

I suggest changing the test to pass "" instead of None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed May 26 17:20:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 15:20:28 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1274887228.26.0.394187502277.issue7150@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As an aside, I dislike the fact that the datetime module uses a C 'int' for date ordinals, and clearly assumes that it'll be at least 32 bits.  int could be as small as 16 bits on some systems (small embedded systems?).  But that's another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Wed May 26 17:23:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 15:23:03 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274887383.02.0.380534871424.issue7879@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This looks fine to me.  Alexander?

----------
nosy: +belopolsky, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 17:23:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 15:23:49 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1274887429.35.0.576720550309.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have untabified James' patch, ran the tests on the result, but did not otherwise review it.

There is a not-so-easy-to-find thread on python-dev discussing this issue under subject "Python 2.6.5".

Here is a relevant quote from  Martin v. L?wis:

"""
That would require that Barry actually *can* judge the issue at hand. In
the specific case, I would expect that Barry would defer the specifics
of the Windows issue to Windows experts, and then listen to what they
say.

I'm personally split whether the proposed patch is correct (i.e. whether
asctime really *can* be implemented in a cross-platform manner; any
definite ruling on that would be welcome). In the past, we had rather
taken approaches like disabling runtime assertions "locally"; not sure
whether such approaches would work for asctime as well.

In any case, I feel that the issue is not security-critical at all.
People just don't pass out-of-range values to asctime, but instead
typically pass the result of gmtime/localtime, which will not cause any
problems.
"""

----------
assignee:  -> belopolsky
components: +Distutils -Extension Modules, Windows
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Wed May 26 17:24:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 15:24:57 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1274887497.87.0.992176521181.issue6608@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file17468/issue6608.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Wed May 26 17:28:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 26 May 2010 15:28:23 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1274887703.77.0.849909018077.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Distutils2 already has a config command used to configure some aspects of C compilation. Not sure if I should expand that or write an unrelated configure command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed May 26 17:31:41 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 May 2010 15:31:41 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274887901.62.0.781489983855.issue5689@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

Per, on 2010-03-17, I asked you via email:

"I was looking at

  http://bugs.python.org/issue5689
  http://bugs.python.org/issue6715

and Martin's comments about the licensing of the bindings; is there a special reason for the lgpl3 license of the bindings, given that both python and xz-utils are not gpl'ed?"

Does pyliblzma need to be licensed under the lgpl3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed May 26 17:37:11 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 26 May 2010 15:37:11 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1274888231.44.0.912038031914.issue8254@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

start a new command from scratch. The configure command is not dealing but with generating a configuration file.

config is implementing a whole compilation chain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed May 26 17:41:53 2010
From: report at bugs.python.org (Jeremy Kloth)
Date: Wed, 26 May 2010 15:41:53 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1274888513.8.0.793902331838.issue8254@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed May 26 17:46:13 2010
From: report at bugs.python.org (jan matejek)
Date: Wed, 26 May 2010 15:46:13 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1274888773.16.0.635952580432.issue8335@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

Tarek,
the error output is this:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.6

the chdir is the problem - because in an environment where you don't have an existing Python installation, you will not find -lpython2.6.

the linker from unixccompiler.py:link() is this:
['gcc', '-pthread', '-shared', '/tmp/pythontest_eosQ1d/tempt/tmp/tmphIMDH2/foo.o', '-L.', '-lpython2.6', '-o', '/tmp/tmppAsk00/foo.so']

and since you're in new temporary directory, -L. does not include libpython2.6 (unless you copy it in that directory or change -L. to the right place)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8335>
_______________________________________

From report at bugs.python.org  Wed May 26 17:51:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 15:51:06 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1274889066.58.0.607584785519.issue6608@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch as written causes buffer overflow for year >= 10,000:

>>> len(time.asctime( (10000, 1, 1, 0, 0, 0, 0, 1, -1)))
26
>>> len(time.asctime( (100000, 1, 1, 0, 0, 0, 0, 1, -1)))
27

while the buffer is only 26 characters:

+       static char result[26];
+
+       sprintf(result, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n",

This can be fixed in multiple ways: changing the year format to %.4d, using PyString_Format, or restricting the year to 4 decimal digits in check_bounds.

A nit pick: you can save some static storage by making wday_name and mon_name and possibly increase performance of asctime 2d arrays instead of arrays of pointers to null-terminated strings.  See http://www.opengroup.org/onlinepubs/009695399/functions/asctime.html .

Just as Martin, I am split on whether the patch is correct.  The fact that it is almost a copy of POSIX reference implementation gives some confidence, but that confidence is taken away by the reference implementation having a buffer overflow bug.

I am also not sure that all systems produce the same end of line character.  I would like to hear from Windows experts.

----------
components: +Extension Modules, Windows -Distutils
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Wed May 26 18:00:31 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 26 May 2010 16:00:31 +0000
Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine
In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za>
Message-ID: <1274889631.51.0.655038718685.issue8823@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

urllib2 is currently catching the socket.error exceptions and presenting the reason as custom URLError exception. To address this issue, the module should catch the httplib raised exceptions also and present it.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8823>
_______________________________________

From report at bugs.python.org  Wed May 26 18:03:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 16:03:47 +0000
Subject: [issue8817] Expose round-to-nearest division algorithm in
	Objects/longobject.c
In-Reply-To: <1274792162.57.0.293855829379.issue8817@psf.upfronthosting.co.za>
Message-ID: <1274889827.86.0.226348543078.issue8817@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed (with the DECREF(one) fix) in r81541.

----------
components: +Interpreter Core
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8817>
_______________________________________

From report at bugs.python.org  Wed May 26 18:08:54 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 26 May 2010 16:08:54 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1274890134.97.0.725708208468.issue8254@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Wed May 26 18:13:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 16:13:42 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274890422.81.0.487682626407.issue7879@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 18:30:58 2010
From: report at bugs.python.org (Alexis Metaireau)
Date: Wed, 26 May 2010 16:30:58 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1274891458.33.0.983009074761.issue8190@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <ametaireau at gmail.com>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8190>
_______________________________________

From report at bugs.python.org  Wed May 26 18:32:00 2010
From: report at bugs.python.org (Alexis Metaireau)
Date: Wed, 26 May 2010 16:32:00 +0000
Subject: [issue4908] Implement PEP 376
In-Reply-To: <1231609506.29.0.511902396455.issue4908@psf.upfronthosting.co.za>
Message-ID: <1274891520.13.0.433762910351.issue4908@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <ametaireau at gmail.com>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4908>
_______________________________________

From report at bugs.python.org  Wed May 26 18:44:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 May 2010 16:44:20 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274892260.06.0.735895237642.issue8806@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (I know, the "context" attribute isn't documented, I'm going to fix
> this)

Now documented at:
http://docs.python.org/dev/py3k/library/ssl.html#ssl.SSLSocket.context

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Wed May 26 18:50:44 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 16:50:44 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274892644.47.0.0910563343191.issue8806@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

If you're fine with the current patch I can go on and commit it (including the context attribute test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Wed May 26 19:01:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 17:01:46 +0000
Subject: [issue8775] Use locale encoding to decode sys.argv,
	not the file system encoding
In-Reply-To: <1274357365.37.0.0731450159524.issue8775@psf.upfronthosting.co.za>
Message-ID: <1274893306.75.0.617297494303.issue8775@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@loewis: You restored the original (wrong) title "Use locale encoding to decode sys.argv, not the file system encoding", instead of the new (good) title "Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)". Is it wanted or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8775>
_______________________________________

From report at bugs.python.org  Wed May 26 19:06:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 17:06:23 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274893583.08.0.710414663119.issue7879@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Mark,

I have zero experience with Windows and don't even have a win32 machine to test the patch.

On the other hand the patch is so simple that I think it can be reviewed based on theoretical considerations.

This is probably bikesheding, but I have a slight preference for  os.name in ("nt", "ce").  The reason is that sys.platform is fixed when python is built while os.name is (in theory) determined at run-time.

Also, sys.platform == "win32", appears to be false on 64 bit Windows, but I think it is actually true.

Finally, explicit better than implicit.  A change from if os.name == "nt" to  os.name in ("nt", "ce") gives obviously a strictly wider check. On the other hand it is not obvious to me how the current patch will affect Cygwin platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 19:09:11 2010
From: report at bugs.python.org (Dan Gawarecki)
Date: Wed, 26 May 2010 17:09:11 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1274893751.54.0.711225048374.issue8402@psf.upfronthosting.co.za>


Dan Gawarecki <dan_gawarecki at datacard.com> added the comment:

Shouldn't the title be updated to indicate the fnmatch is the true source of the behavior (I'm basing this on http://docs.python.org/library/glob.html indicating the fnmatch is invoked by glob).  I'm not using glob, but fnmatch in my attempt to find filenames that look like "Ajax_[version2].txt".  

If nothing else, it would have helped me if the documentation would state whether or not the brackets could be escaped.  It doesn't appear from my tests (trying "Ajax_\[version2\].txt" and "Ajax_\\[version2\\].txt") that 'escaping' is possible, but if the filter pattern gets turned into a regular expression, I think escaping *would* be possible.  Is that a reasonable assumption?

I'm running 2.5.1 under Windows, and this is my first ever post to the bugs list.

----------
nosy: +Aquinas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Wed May 26 19:09:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 17:09:17 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1274893757.85.0.741781859051.issue4768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I wrote a patch for base64.b64encode() to accept str (str is encoded to utf-8): patch attached to #4768. It should fix this issue, but we can add the tests of email_base64_bytes.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4768>
_______________________________________

From report at bugs.python.org  Wed May 26 19:15:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 17:15:05 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274894105.5.0.210189005375.issue7879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

sys.platform will be "win32" for both 32 and 64-bit Windows.

As for Cygwin, os.name is "posix" there, and sys.platform is "cygwin", so it should be unaffected.

The patch looks fine to me, and we do typically use sys.platform more often than the os.name check.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 19:17:11 2010
From: report at bugs.python.org (Dan Gawarecki)
Date: Wed, 26 May 2010 17:17:11 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1274894231.99.0.514782737846.issue8402@psf.upfronthosting.co.za>


Dan Gawarecki <dan_gawarecki at datacard.com> added the comment:

Following up...
I saw Eric Smith's 2nd note (2010-04-15 @1:27) about fnmatch.translate documentation stating that
   "There is no way to quote meta-characters."

When I looked at:
http://docs.python.org/library/fnmatch.html#module-fnmatch

did not see this statement appear anywhere.  Would this absence be because someone is working on making this enhancement?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Wed May 26 19:23:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 17:23:17 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274894597.24.0.907003232648.issue7879@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

OK, I'll commit it then.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 19:33:01 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 26 May 2010 17:33:01 +0000
Subject: [issue8402] glob returns empty list with "[" character in the folder
	name
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1274895181.96.0.974788371673.issue8402@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't think so. That quote came from the docstring for fnmatch.translate.

>>> help(fnmatch.translate)
Help on function translate in module fnmatch:

translate(pat)
    Translate a shell PATTERN to a regular expression.
    
    There is no way to quote meta-characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8402>
_______________________________________

From report at bugs.python.org  Wed May 26 19:35:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 17:35:26 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1274895326.9.0.29353681183.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think one more skip is required in test_socketserver.

Fixed: 2.7 (r81543), 3.2 (r81545), 3.1 (r81546). Blocked in 2.6 (r81544).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Wed May 26 19:36:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 May 2010 17:36:47 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

This doc improvement suggestion is inspired by #991196 (and subsequent duplicates) and the current discussion on py-dev in the thread
  'variable name resolution in exec is incorrect'
(which is not a correct claim). I believe there is consensus that the doc for exec needs improving.

My suggestion (which others may amend) is that the following paragraph (from the 3.x builtin functions exec entry)

"In all cases, if the optional parts are omitted, the code is executed in the current scope. If only globals is provided, it must be a dictionary, which will be used for both the global and the local variables. If globals  and locals are given, they are used for the global and local variables, respectively. If provided, locals can be any mapping object."

have these two sentences added:

"If only globals is provided or if onedict is provided as both globals and locals, the code is executed in a new top-level scope. If different objects are given as globals and locals, the code is executed as if it were in a class statement in a new top-level scope."

----------
assignee: docs at python
components: Documentation
messages: 106552
nosy: docs at python, tjreedy
priority: normal
severity: normal
status: open
title: Improve documentation of exec
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Wed May 26 19:44:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 May 2010 17:44:05 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1274863869.25.0.308368668911.issue5689@psf.upfronthosting.co.za>
Message-ID: <4BFD5DE2.7070005@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 26.05.2010 10:51, schrieb Antoine Pitrou:
>
> Antoine Pitrou<pitrou at free.fr>  added the comment:
>
>> If the underlying library is LGPL, it would
>> require us to distribute its sources along with the Windows binaries,
>> which I'm not willing to do.
>
> Martin, this is wrong, you don't have to bundle the source *in* the object code package.

That's why I said "along". I'm still not willing to do that: making the 
source available is still inconvenient. More importantly, anybody 
redistributing Python binaries would have to comply also (e.g. on 
CD-ROMs or py2exe binaries); this is a burden I don't want to impose
on our users. Fortunately, we don't have to, as the LZMA compression 
itself is in the public domain. For the Python wrapper, I hope that 
somebody contributes such a module under a PSF contributor agreement.
If nobody else does, I may write one from scratch one day.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed May 26 19:44:21 2010
From: report at bugs.python.org (C Moss)
Date: Wed, 26 May 2010 17:44:21 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>


New submission from C Moss <cm.byu.fan at gmail.com>:

The expression int("0",0) throws an exception, though the expectation would be to return 0 (zero).

int("0x0",0) == 0
int("00",0) = 0

----------
components: None
messages: 106554
nosy: cmoss60
priority: normal
severity: normal
status: open
title: int("0",0) throws exception
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 19:52:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 May 2010 17:52:45 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274896365.44.0.690368816474.issue8824@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To be super-clear, consider adding one more sentence, something like

"The result for code with def statements or lambda expressions may be different than it would be if the implied context were a function rather than a class."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Wed May 26 19:56:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 17:56:42 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274896602.44.0.732190628778.issue8825@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  It works for me:

Python 2.6.5 (r265:79063, May 18 2010, 17:12:15) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> int("0", 0)
0

What version of Python are you using, and on what platform.  Also, please could you show the exact code you used and the full exception traceback?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 20:01:58 2010
From: report at bugs.python.org (Tomas Zulberti)
Date: Wed, 26 May 2010 18:01:58 +0000
Subject: [issue8826] Invalid expires date in cookiejar
In-Reply-To: <1274896918.81.0.357583266037.issue8826@psf.upfronthosting.co.za>
Message-ID: <1274896918.81.0.357583266037.issue8826@psf.upfronthosting.co.za>


New submission from Tomas Zulberti <tzulberti at gmail.com>:

This happens when creating a SimpleCookie from an string. The value in the cookie is: "expires=Fri, 31-Dec-2010 23:59:59 GMT"

But in the cookiejar, the value if only "Fri,". 

As far as I know, the error is in the regular expresion _LegalCharsPatt, that doesn't allows whitespaces. The format of the expires date was taken from the wikipedia: http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_attributes

----------
components: None
messages: 106557
nosy: tzulberti
priority: normal
severity: normal
status: open
title: Invalid expires date in cookiejar
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8826>
_______________________________________

From report at bugs.python.org  Wed May 26 20:02:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 18:02:42 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274896962.72.0.253579602637.issue8825@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Works fine on 2.6 and 3.1 on Windows.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 20:04:00 2010
From: report at bugs.python.org (C Moss)
Date: Wed, 26 May 2010 18:04:00 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274896602.44.0.732190628778.issue8825@psf.upfronthosting.co.za>
Message-ID: <4bfd628c.8c43e70a.68d9.0fba@mx.google.com>


C Moss <cm.byu.fan at gmail.com> added the comment:

I'm using MS IronPython 2.6 which is using CPython 2.6.1.

Regards,

Clark

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 20:05:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 26 May 2010 18:05:54 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274897154.46.0.31780265855.issue8825@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW it works fine on 2.6/2.7/3.1/3.2 on Linux too.

----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 20:07:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 18:07:07 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274897227.95.0.589864331705.issue8825@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That's an IronPython bug, and I see the same thing as you when I run on IP 2.6. You could submit a bug report to them here: http://ironpython.codeplex.com/workitem/list/basic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 20:07:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 18:07:24 +0000
Subject: [issue8806] ftplib should support SSL contexts
In-Reply-To: <1274717262.45.0.585988052804.issue8806@psf.upfronthosting.co.za>
Message-ID: <1274897244.06.0.433810128076.issue8806@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r81548.

----------
components: +Library (Lib)
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8806>
_______________________________________

From report at bugs.python.org  Wed May 26 20:09:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 May 2010 18:09:24 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274897364.51.0.482174884922.issue8825@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We ought to add a test case for this so that other implementations can detect an error.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 20:11:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 18:11:28 +0000
Subject: [issue2810] _winreg.EnumValue sometimes raises WindowsError ("More
	data is available")
In-Reply-To: <1210441054.55.0.264831714691.issue2810@psf.upfronthosting.co.za>
Message-ID: <1274897488.87.0.924205517346.issue2810@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to py3k in r81547 and release31-maint in r81546.

Thanks for the patch!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2810>
_______________________________________

From report at bugs.python.org  Wed May 26 20:25:01 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 26 May 2010 18:25:01 +0000
Subject: [issue5094] datetime lacks concrete tzinfo impl. for UTC
In-Reply-To: <1233190363.25.0.24659427347.issue5094@psf.upfronthosting.co.za>
Message-ID: <1274898301.6.0.0536210230163.issue5094@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

PyPy has said over the years they plan to commit their version of datetime, they just need to get around to it. I just figured that we could use this opportunity to prepare for it. But if people want to do the C version first, that's fine as they will be the ones writing the patch. I just thought that if someone would rather write a patch to create datetime.py now along with a pure Python version of the proposed class they could.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________

From report at bugs.python.org  Wed May 26 20:29:52 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Wed, 26 May 2010 18:29:52 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1274898592.56.0.404683121086.issue5689@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

if you're already looking at issue6715, then I don't get why you're asking.. ;)

quoting from msg106433:
"For my code, feel free to use your own/any other license you'd like or even public domain (if the license of bz2module.c that much of it's derived from permits of course)!"

The reason why I picked LGPLv3 in the past was simply just because liblzma at the time was licensed under it, so I just picked the same for simplicity.
I've actually already dual-licensed it under the python license in addition on the project page though, but I just forgot updating the module's metadata as well before I released 0.5.3 last month..

Martin: For LGPL (or even GPL for that matter, disregarding linking restrictions) libraries you don't have to distribute the sources of those libraries at all (they're already made available by others, so that would be quite overly redundant, uh?;). LGPL actually doesn't even care at all about the license of your software as long as you only dynamically link against it.

I don't really get what the issue would be even if liblzma were still LGPL, it doesn't prohibit you from distributing a dynamically linked library along with python either if necessary (which of course would be of convenience on win32..)..

tsktsk, discussions about python module for xz compression should anyways be kept at issue6715 as this one is about the tarfile module ;p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed May 26 20:48:56 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Wed, 26 May 2010 18:48:56 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274899736.98.0.738232132476.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

Yeah, I guess I anyways can just break the current API right away to make it compatible with future changes, I've already figured since long ago how it should look like. It's not like I have to implement the actual functionality to ensure compatibility, no-op works like charm. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 21:11:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 19:11:20 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274901080.65.0.251779963866.issue8825@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Added some test cases in r81551 (trunk) and r81552 (release26-maint).

I'll merge these to py3k.  But I notice that the rules for py3k are a little odd:

>>> int('0000', 0)
0
>>> int('0001', 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 0: '0001'

I expected the prohibition on leading zeros to apply to the first example, as well as the second.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 21:11:58 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 19:11:58 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274901118.85.0.225603668388.issue8825@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 21:19:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 19:19:30 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274901570.67.0.0287734514375.issue8825@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tests merged to 3.x in r81553, r81554.  Closing.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 21:24:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 26 May 2010 19:24:34 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1274901874.39.0.518287766937.issue8825@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Wed May 26 21:31:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 19:31:31 +0000
Subject: [issue8827] poplib.POP3_SSL doesn't have an actual test suite
In-Reply-To: <1274902291.16.0.0457634401694.issue8827@psf.upfronthosting.co.za>
Message-ID: <1274902291.16.0.0457634401694.issue8827@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As done for ftplib.FTP_TLS the tests executed in TestPOP3Class should be replicated to use poplib.POP3_SSL instead of poplib.POP3.

asyncore-based SSL test server used in test_ftplib.py can be used as an example on how to do this.

----------
assignee: giampaolo.rodola
components: Tests
messages: 106570
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: poplib.POP3_SSL doesn't have an actual test suite
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8827>
_______________________________________

From report at bugs.python.org  Wed May 26 21:40:25 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 19:40:25 +0000
Subject: [issue8827] poplib.POP3_SSL doesn't have an actual test suite
In-Reply-To: <1274902291.16.0.0457634401694.issue8827@psf.upfronthosting.co.za>
Message-ID: <1274902825.97.0.746329312337.issue8827@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm sorry, it seems I'm wrong.
Ignore this.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8827>
_______________________________________

From report at bugs.python.org  Wed May 26 21:54:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 May 2010 19:54:05 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274903645.9.0.375315613518.issue6715@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

[Replying to msg106566]

> if you're already looking at issue6715, then I don't get why you're
> asking.. ;)

Can you please submit a contributor form?


> Martin: For LGPL (or even GPL for that matter, disregarding linking
> restrictions) libraries you don't have to distribute the sources of
> those libraries at all (they're already made available by others, so
> that would be quite overly redundant, uh?;). LGPL actually doesn't
> even care at all about the license of your software as long as you
> only dynamically link against it.

Of course you do. Quoting from the LGPL

"You may convey a Combined Work ... if you also do each of the following:
 ...
 d) Do one of the following:
    0) Convey the Minimal Corresponding Source under the terms of this 
       License, and the Corresponding Application Code in a form 
       suitable for, and under terms that permit, the user to recombine 
       or relink the Application with a modified version of the Linked 
       Version to produce a modified Combined Work, in the manner 
       specified by section 6 of the GNU GPL for conveying 
       Corresponding Source.
    1) [not applicable to Windows]
"

> I don't really get what the issue would be even if liblzma were still
> LGPL, it doesn't prohibit you from distributing a dynamically linked
> library along with python either if necessary (which of course would
> be of convenience on win32..)..

Of course I can distribute a copy of an lzma DLL. However, I would have to provide ("convey") a copy of the source code of that DLL as well.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 21:54:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 May 2010 19:54:33 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1274898592.56.0.404683121086.issue5689@psf.upfronthosting.co.za>
Message-ID: <4BFD7C76.90409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> tsktsk, discussions about python module for xz compression should
> anyways be kept at issue6715 as this one is about the tarfile module
> ;p

Ok, following up there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed May 26 22:06:38 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 26 May 2010 20:06:38 +0000
Subject: [issue8807] poplib should support SSL contexts
In-Reply-To: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>
Message-ID: <1274904398.34.0.90831135023.issue8807@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment.
The same approach adopted for ftplib (issue 8806) was used.

----------
keywords: +patch
Added file: http://bugs.python.org/file17469/poplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8807>
_______________________________________

From report at bugs.python.org  Wed May 26 22:31:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 20:31:16 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274905876.15.0.857872345551.issue7879@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r81555 (trunk) and r81556 (py3k).  Is this a 2.6 backport candidate?  I don't think so.

Leaving this open to consider using newer unittest.skipIf mechanism.  See attached patch, issue7879.diff.

----------
Added file: http://bugs.python.org/file17470/issue7879.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 22:36:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 May 2010 20:36:33 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274906193.24.0.487620485708.issue7879@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The skipIf patch looks good to me (though I haven't tested it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 22:38:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 20:38:07 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274906287.45.0.506666404341.issue7879@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>From IRC:

Taggnostr: imho tests and doc updates can be backported

----------
keywords: +26backport

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 22:39:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 20:39:39 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274906379.5.0.268935313448.issue7879@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 22:47:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 May 2010 20:47:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1274903645.9.0.375315613518.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274906842.3162.41.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Of course I can distribute a copy of an lzma DLL. However, I would
> have to provide ("convey") a copy of the source code of that DLL as
> well.

Can you tell me where you are currently providing the source code for
the readline library, or the gdbm library?

Oh, and by the way, you should probably shut down PyPI, since there are
certainly Python wrappers for LGPL'ed libraries there (or even GPL'ed
one), and you aren't offering a link to download those libraries' source
code either.

You seem to have no problem "conveying" copies for the source code of
non-LGPL libraries such as OpenSSL. Why is that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 22:50:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 26 May 2010 20:50:24 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1274907024.54.0.4545609676.issue7879@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

SkipIf patch committed in r81559 (trunk) and r81560 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Wed May 26 23:01:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 May 2010 21:01:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1274906842.3162.41.camel@localhost.localdomain>
Message-ID: <4BFD8C1B.8090207@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can you tell me where you are currently providing the source code for
> the readline library, or the gdbm library?

We don't, as they aren't included in the Windows distribution. The 
readline library doesn't work on Windows, anyway, and instead of gdbm, 
we had traditionally been distributing bsddb instead on Windows.

> Oh, and by the way, you should probably shut down PyPI, since there are
> certainly Python wrappers for LGPL'ed libraries there (or even GPL'ed
> one), and you aren't offering a link to download those libraries' source
> code either.

This is off-topic for this bug tracker. Please remain objective and 
professional if you can manage to.

> You seem to have no problem "conveying" copies for the source code of
> non-LGPL libraries such as OpenSSL. Why is that?

Not sure what you are referring to. We don't provide the sources for the 
OpenSSL libraries along with the Windows installer, because the license 
of OpenSSL doesn't require us to. This is very convenient for our users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 23:15:37 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 May 2010 21:15:37 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1274908537.3.0.617191567997.issue6715@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 23:34:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 May 2010 21:34:49 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <4BFD8C1B.8090207@v.loewis.de>
Message-ID: <1274909621.3162.71.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Oh, and by the way, you should probably shut down PyPI, since there are
> > certainly Python wrappers for LGPL'ed libraries there (or even GPL'ed
> > one), and you aren't offering a link to download those libraries' source
> > code either.
> 
> This is off-topic for this bug tracker. Please remain objective and 
> professional if you can manage to.

This whole subthread was already off-topic (since it was pointed out,
before your previous message, that the underlying lib is in the public
domain).

Actually, I would argue that the whole idea of promoting a rigorous
interpretation of a license has no place on the bug tracker. It makes no
sense to do this on an ad hoc fashion, especially if you want lawyers to
be involved (they are certainly not reading this).

(of course, you will also have understood that I disagree with such a
rigorous interpretation)

> Not sure what you are referring to. We don't provide the sources for the 
> OpenSSL libraries along with the Windows installer, because the license 
> of OpenSSL doesn't require us to. This is very convenient for our users.

This was not about providing the sources together with the installer
(which even the GPL or the LGPL don't require to do), but providing them
as a separate bundle on the download site.
We do have a copy of the OpenSSL source tree somewhere, it is used by
the Windows build process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed May 26 23:54:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 21:54:08 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1274910848.73.0.747529793695.issue8651@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

getarg.patch fixes STORE_SIZE macro used in convertsimple(). If the input size is bigger than INT_MAX, it raises an OverflowError("size does not fit in an int") and calls converterr() which expected="".

The value of expected is useless because converterr() is only used to notice that an error occured. I think that return msgbuf instead of calling converterr() would be enough, but I don't know this code very well and so i copied the code used to raise an OverflowError for the 'b' format.

----------
keywords: +patch
Added file: http://bugs.python.org/file17471/getarg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Wed May 26 23:55:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 21:55:01 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1274910901.82.0.126429179342.issue8651@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another test (only requires ~2 GB of memory, not 4 GB or more) for the patch:

import _elementtree
def test():
    parser=_elementtree.XMLParser()
    text='s' * (2**31 + 10)
    try:
        parser.feed(text)
    except OverflowError as err:
        print("ok: %s" % err)
        return
    except:
        pass
    print("error: OverflowError not raised")
test()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Wed May 26 23:56:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 21:56:32 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1274910992.34.0.976622183014.issue8650@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also a related issue: #8651.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Thu May 27 00:14:22 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 26 May 2010 22:14:22 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274912062.44.0.368690413049.issue8811@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Thu May 27 01:18:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 23:18:52 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1274915932.43.0.889518350451.issue8604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This sounds silly to me. You can write a file in two lines:
>
> with open("foo", "wb") as f:
>    f.write(contents)

If the disk is full, write fails and the new file only contains a part of 'contents'. If the file does already exist and the write fails, the original content is lost.

The correct pattern is something like:

@contextlib.contextmanager
def atomic_write(filename):
  tempname = filename + ".tmp"
  out = open(tempname, "w")
  try:
     yield out
     if hasattr('os', 'fsync'):
        os.fsync(out.fileno())
     out.close()
     if os.name in ('nt', 'ce'):
        os.unlink(filename)
        # ... hope that it doesn't fail here ...
     os.rename(tempname, filename)
  except:
     out.close()
     os.unlink(tempname)
     raise

Remarks:
 - call fsync() to ensure that the new file content is written on disk. it does nothing on Mac OS X
 - on Windows, it's not possible to rename a to b if b does already exist. New Windows versions has an atomic function: MoveFileTransacted(). Older versions have MoveFileEx(MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH) and ReplaceFile()

This context manager is *not* atomic on any OS. It's only atomic on some OS, and it may depends on the kernel version (see recent discussions about ext3/ext4, fsync and write barrier).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu May 27 01:26:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 23:26:13 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1274916373.55.0.988179873315.issue8604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

An article about ext3 and fsync: "Solving the ext3 latency problem"
http://lwn.net/Articles/328363/

Another good article, written by the maintainer of ext4 (Theodore Ts'o): "Don?t fear the fsync!"
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu May 27 01:41:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 23:41:41 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

os.rename() is atomic on Linux, but on Windows it raises an error if the destination does already exist.

Not atomic pseudo-code for Windows:
  if exists(b):
     unlink(b)
  rename(a, b)

Windows offers different functions depending on the version:
 - MoveFileTransacted(): atomic! version >= (Windows Vista, Windows Server 2008)
 - ReplaceFile(): version >= Windows 2000
 - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be moved to a different volume, the function simulates the move by using the CopyFile and DeleteFile functions."), version >= Windows 2000

I don't think that it's possible to write an atomic rename (file) function for any OS, so it's only a "best effort" atomic function. The documentation will give a list of OS on which the operation *is* atomic (eg. Linux).

Note: os.rename() uses MoveFileW() on Windows.

----------
components: Library (Lib), Windows
messages: 106587
nosy: haypo
priority: normal
severity: normal
status: open
title: Atomic function to rename a file
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 01:42:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 May 2010 23:42:24 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1274917344.96.0.777880493633.issue8604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We need an atomic rename function to implement atomic_write(): I opened a new issue, #8828.

----------
dependencies: +Atomic function to rename a file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu May 27 02:05:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 May 2010 00:05:32 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274918732.92.0.975939677331.issue8824@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 27 02:12:20 2010
From: report at bugs.python.org (Celia Horne)
Date: Thu, 27 May 2010 00:12:20 +0000
Subject: [issue8829] IDLE editior not opening
In-Reply-To: <1274919139.94.0.215202967128.issue8829@psf.upfronthosting.co.za>
Message-ID: <1274919139.94.0.215202967128.issue8829@psf.upfronthosting.co.za>


New submission from Celia Horne <oneidiotinatree at gmail.com>:

Hey there!

I'm very new to Python, but I've been getting along fairly well. However, last night I tried to open the IDLE editor (on its own and with a .py file)but nothing would open. It just sat there acting like it was going to load, but still nothing occurred.

Originally I was using version 2.6.5, but I started experiencing these same problems with it. I looked online but could find no help or suggestions. I tried uninstalling/reinstalling, I made sure I am already set as the Admin, (as I am the only user on this computer, and there is only my account, not even a guest account) and I looked to see if there was a Windows Vista patch or Vista-only issue, but to no avail. At this point, I am completely lost and I really need some assistance.

I installed the newer version (3.1.2) and I'm still having the same issues. The CMD prompt works just fine, as it did with the older version, but nothing I do can bring up the IDLE editor.

Any help would be VERY appreciated, because I was really looking forward to using and learning python, but now I'm feeling very defeated.

Thanks

----------
components: IDLE, Windows
messages: 106589
nosy: Celia.Horne
priority: normal
severity: normal
status: open
title: IDLE editior not opening
type: performance
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8829>
_______________________________________

From report at bugs.python.org  Thu May 27 03:25:10 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 27 May 2010 01:25:10 +0000
Subject: [issue8830] Add nondestructive selection to sets
In-Reply-To: <1274923510.24.0.670260490915.issue8830@psf.upfronthosting.co.za>
Message-ID: <1274923510.24.0.670260490915.issue8830@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

I see in a lot of references for computer programming a function that returns an arbitrary value from a standard or frozen set. http://en.wikipedia.org/wiki/Set_%28computer_science%29 describes it as pick. It surprised me when I discovered that Python sets don't have this method. I would suggest the returned value be somewhat random to prevent repeated calls from returning repeated results. Perhaps a small C-level counter could control that, which can then roll over uneventfully if enough calls are made.

----------
components: None
messages: 106590
nosy: ipatrol
priority: normal
severity: normal
status: open
title: Add nondestructive selection to sets
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8830>
_______________________________________

From report at bugs.python.org  Thu May 27 03:36:14 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 27 May 2010 01:36:14 +0000
Subject: [issue8830] Add nondestructive selection to sets
In-Reply-To: <1274923510.24.0.670260490915.issue8830@psf.upfronthosting.co.za>
Message-ID: <1274924174.77.0.906833976549.issue8830@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is a dupe of issue 7212.

----------
nosy: +eric.smith
resolution:  -> duplicate
status: open -> closed
superseder:  -> Retrieve an arbitrary element from a set without removing it

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8830>
_______________________________________

From report at bugs.python.org  Thu May 27 03:43:57 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 27 May 2010 01:43:57 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1274924637.36.0.858882495507.issue7212@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

I still see a use in this. I like to use sets for lists of servers or mirrors. There is no compelling reason *not* to add a get() or pick() method, as described in http://en.wikipedia.org/wiki/Set_%28computer_science%29. Sets could be used for many things that lists are currently used for. I request for this to be reopened given the lapse since any action on this.

----------
components: +Interpreter Core -Library (Lib)
nosy: +ipatrol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Thu May 27 03:46:50 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 27 May 2010 01:46:50 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1274924810.26.0.277336947147.issue7212@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

I support http://bugs.python.org/msg94599 with a check to see if the length is 0, and rename it pick (based on the generic programming and mathematical literature).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Thu May 27 04:24:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 May 2010 02:24:30 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1274927070.89.0.125345754888.issue7212@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Use set.pop().  

Or if you don't want mutation, then use next(iter(s)) or next(iter(s),default).   This technique also works for any collection including dicts and deques and whatnot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Thu May 27 09:03:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 May 2010 07:03:24 +0000
Subject: [issue2844] int() lies about base parameter
In-Reply-To: <1210673035.74.0.555246822521.issue2844@psf.upfronthosting.co.za>
Message-ID: <1274943804.44.0.155395028301.issue2844@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For py3k, this was fixed in r81557.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2844>
_______________________________________

From report at bugs.python.org  Thu May 27 10:22:53 2010
From: report at bugs.python.org (kookwekker)
Date: Thu, 27 May 2010 08:22:53 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1274948573.04.0.959396463901.issue7171@psf.upfronthosting.co.za>


Changes by kookwekker <dodehoekspiegel at gmail.com>:


----------
nosy: +kookwekker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Thu May 27 10:43:14 2010
From: report at bugs.python.org (Alessandro Roat)
Date: Thu, 27 May 2010 08:43:14 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>


New submission from Alessandro Roat <alexroat at gmail.com>:

A thread blocked on a recv or a recvfrom method on a UDP socket (waiting for a datagram) can not be unlocked calling a .close() from a different thread.
This is in contrast with the standard C++/C behavior, where a close() on a socket causes an asynchronous and immediate exception/return with error on the functions that are using the socket at the same time (but in another thread).
Thus, it is impossible to unlock a waiting recv/recvfrom calling a close() or a shutdown() if no more datagrams are coming.

----------
components: IO
messages: 106596
nosy: Alessandro.Roat
priority: normal
severity: normal
status: open
title: recv and recvfrom on UDP socket do not return/throw exception after a close()
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Thu May 27 11:03:32 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 27 May 2010 09:03:32 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274951012.32.0.022602037403.issue8831@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Thu May 27 11:05:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 27 May 2010 09:05:31 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1274951131.13.0.760696661089.issue7171@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Thu May 27 11:19:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 27 May 2010 09:19:32 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274951972.82.0.025514465566.issue8831@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you provide a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Thu May 27 11:34:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 09:34:31 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274952871.62.0.145980897202.issue8831@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

And maybe also a short example? :)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Thu May 27 11:41:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 09:41:11 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274953271.8.0.0830872830291.issue8828@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 11:45:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 09:45:59 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274953559.42.0.416381234076.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A first implementation can be:

if os.name in ('nt', 'ce'):
   def atomic_rename(a, b):
      if os.path.exists(b):
         unlink(b)
      rename(a, b)
else:
   atomic_rename = os.rename

This implementation is atomic on POSIX, and not atomic on Windows. Tell me if I am wrong.

It can be improved later by adding the support of better Windows functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 11:46:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 27 May 2010 09:46:19 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274953579.25.0.676380725325.issue8828@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 11:47:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 09:47:25 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274953645.28.0.406405089566.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See issue #8604: proposal of a new "with atomic_write(filename) as fp: ..." context manager.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 11:58:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 09:58:56 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274954336.17.0.28560552817.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Begin by removing the dest file is maybe not the safer approach :-) Here is a new try: begin by renaming the dest file to a new file.

------
# use maybe a PRNG instead of a dummy counter or tempfile
def _create_old_filename(filename):
   old = filename + '.old'
   index = 2
   while os.path.exists(old):
      old = filename + '-%s.old' % index
      index += 1
   return old

if os.name in ('nt', 'ce'):
   def atomic_rename(src, dst):
      if os.path.exists(dst):
         old = _create_old_filename(dst)
         rename(dst, old)
         rename(src, dst)
         unlink(old)
      else:
         rename(src, dst)
else:
   atomic_rename = os.rename
------

What can we do if "rename(src, dst)" fails?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 12:03:17 2010
From: report at bugs.python.org (Trundle)
Date: Thu, 27 May 2010 10:03:17 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274954597.77.0.151585763117.issue8828@psf.upfronthosting.co.za>


Changes by Trundle <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 12:10:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 10:10:26 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274955026.86.0.141813912228.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This implementation is atomic on POSIX, ...

Wrong :-)


"On how rename is broken in Mac OS X"
http://www.weirdnet.nl/apple/rename.html

"Update January 8, 2010: ... the original bug (5398777) was resolved in Snow Leopard but the issue I reported was not fixed. ..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 12:32:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 10:32:41 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274956361.36.0.377096569346.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We have to think about network file systems like NFS. Gnome (nautilus) had a bug on rename because NFS emitted a delete notification on a rename:
http://linux-nfs.org/pipermail/nfsv4/2009-March/010134.html
https://bugzilla.gnome.org/show_bug.cgi?id=575684

It looks like rename is atomic, it's just a bug about notification. But other virtual file systems may not implement atomic rename (eg. is rename atomic with sshfs?). Should Python detect the file system type to choose the algorithm? I would like to say no, because I consider that as a file system (or kernel) bug, not a Python bug.

--

Should we also implement a atomic version of shutil.move()? Support rename if the source and the destination are on different file systems. Or is shutil.move() already atomic?

Note: this issue is only about renaming a *file*. Atomic rename of a directory is much more complex :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 12:44:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 10:44:21 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274957061.05.0.103779954667.issue8828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems you are proposing to call "atomic" something which isn't atomic:

   def atomic_rename(src, dst):
      if os.path.exists(dst):
         old = _create_old_filename(dst)
         rename(dst, old)
         rename(src, dst)
         unlink(old)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 12:51:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 10:51:46 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274957506.17.0.927067769564.issue8828@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitrou: Yes, as I wrote: it's not possible to write an atomic function for all OS. The documentation must give a list of the OS on which the function is atomic. Would you prefer to not define the function instead of writing a pseudo-atomic function?

--

Java bug opened in 1996, closed with "Will Not Fix", last comment ("i am facing similar issue...") in 2008:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4017593

"How to do atomic writes in a file" in a MSDN blog:
http://blogs.msdn.com/b/adioltean/archive/2005/12/28/507866.aspx

Extract: "Sometimes shell operations like Delete, Rename can fail for various reasons. For example, it might just happen that an antivirus or content indexing application randomly scans the whole file system once in a while. So, potentially, the file Foo.Tmp.txt will be opened for a short period which will cause ... failed delete. And, not only that, but also Rename can fail if the old file already exists, and someone has an open handle on it."

To avoid that "antivirus or content indexing application" open the file, we may need to use a lock on the files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 12:52:27 2010
From: report at bugs.python.org (Alessandro Roat)
Date: Thu, 27 May 2010 10:52:27 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274957547.96.0.344790911671.issue8831@psf.upfronthosting.co.za>


Alessandro Roat <alexroat at gmail.com> added the comment:

This is an example, test it with netcat (nc -u localhost 8888) on linux (ubuntu 9.10).
Lauch it with python <scriptname>, a prompt will appear.
Type "start" to launch the server, test the server sending UDP packets with netcat, the lenght of packet will be correctly printed.
However, when you'll type "stop" the close will be invoked but the receiving thread wont stop and the join in the stop() wont never return and you will need to kill the python interpreter.


import socket
import threading
import sys
import select


class UDPServer:
    def __init__(self):
        self.s=None
        self.t=None
    def start(self,port=8888):
        if not self.s:
            self.s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
            self.s.bind(("",port))
            self.t=threading.Thread(target=self.run)
            self.t.start()
    def stop(self):
        if self.s:
            self.s.close()
            self.t.join()
            self.t=None
    def run(self):
        while True:
            try:
                data,addr=self.s.recvfrom(1024)
                print "recv done"
                if len(data)<=0:
                    raise
                self.onPacket(addr,data)
            except:
                break
        #chiusura socket
        print "server is no more running"
        self.s=None
    def onPacket(self,addr,data):
        print len(data)


us=UDPServer()
while True:
    sys.stdout.write("UDP server> ")
    cmd=sys.stdin.readline()
    if cmd=="start\n":
        print "starting server..."
        us.start(8888)
        print "done"
    elif cmd=="stop\n":
        print "stopping server..."
        us.stop()
        print "done"
    elif cmd=="quit\n":
        print "Quitting ..."
        us.stop()
        break;

print "bye bye"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Thu May 27 13:35:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 11:35:59 +0000
Subject: [issue8831] recv and recvfrom on UDP socket do not return/throw
	exception after a close()
In-Reply-To: <1274949794.75.0.209181492423.issue8831@psf.upfronthosting.co.za>
Message-ID: <1274960159.6.0.0914301332578.issue8831@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This is in contrast with the standard C++/C behavior, where a close()
> on a socket causes an asynchronous and immediate exception/return with
> error on the functions that are using the socket at the same time (but
> in another thread).

Are you sure of that? I don't see how Python behaviour would be different to a the same program written in C. Could you write a short example written in C to prove that?

--

To avoid this issue (Python blocks on recv() whereas a thread closed the socket), you should check that there is data on the socket before reading the data. Eg. TCPServer.serve_forever() uses select.select() to avoid this issue. Extract:

   while not self.__shutdown_request:
       # XXX: Consider using another file descriptor or
       # connecting to the socket to wake this up instead of
       # polling. Polling reduces our responsiveness to a
       # shutdown request and wastes cpu at all other times.
       r, w, e = select.select([self], [], [], poll_interval)
       if self in r:
           self._handle_request_noblock()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8831>
_______________________________________

From report at bugs.python.org  Thu May 27 14:11:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 12:11:21 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274962281.31.0.664660375515.issue8828@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Would you prefer to not define the function instead of writing a pseudo-
> atomic function?

Your current implementation is useless, since it doesn't achieve anything new.
Besides, if the function isn't atomic, don't name it atomic_XXX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 14:24:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 12:24:22 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274962281.31.0.664660375515.issue8828@psf.upfronthosting.co.za>
Message-ID: <201005271424.13812.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Antoine Pitrou <pitrou at free.fr> added the comment:
> > Would you prefer to not define the function instead of writing a pseudo-
> > atomic function?
> 
> Your current implementation is useless, since it doesn't achieve anything
> new. Besides, if the function isn't atomic, don't name it atomic_XXX.

Someone may reimplement it with unlink+rename which is worse :-)

But ok, you prefer to not define the function if no real atomic implementation 
can be written.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 15:03:02 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 27 May 2010 13:03:02 +0000
Subject: [issue8832] automate minidom.unlink() with a context manager
In-Reply-To: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>
Message-ID: <1274965382.14.0.210712489615.issue8832@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

It is all to easy to forget to "unlink()" minidom documents resulting in huge memory usage.
This patch allows to automate that process with a context manager, similar to how files can be closed in the same way:

with xml.dom.minidom.parse() as dom:
    workwith(dom)

will automatically call dom.unlink() when context manager is exited.
Patch provided.

----------
components: Library (Lib)
files: minidomcontext.patch
keywords: easy, needs review, patch, patch
messages: 106610
nosy: krisvale
priority: normal
severity: normal
status: open
title: automate minidom.unlink() with a context manager
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17472/minidomcontext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8832>
_______________________________________

From report at bugs.python.org  Thu May 27 15:54:03 2010
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 27 May 2010 13:54:03 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1274968443.98.0.570708780157.issue8828@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Thu May 27 16:58:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 27 May 2010 14:58:46 +0000
Subject: [issue8405] Improve test_os._kill (failing on slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1274972326.91.0.170998180498.issue8405@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I just noticed the other day that a buildbot failed because of this issue. Attached is a patch which removes the unconditional 0.5 sleep, and increases the loop to run 100 times. It should cover the worst case of a super slow buildbot, but is still typically complete in tenths of a second in the common case.

----------
Added file: http://bugs.python.org/file17473/issue8405.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8405>
_______________________________________

From report at bugs.python.org  Thu May 27 18:07:09 2010
From: report at bugs.python.org (Justin Bronder)
Date: Thu, 27 May 2010 16:07:09 +0000
Subject: [issue8833] tarfile:  broken hardlink handling and testcase.
In-Reply-To: <1274976429.42.0.686584361847.issue8833@psf.upfronthosting.co.za>
Message-ID: <1274976429.42.0.686584361847.issue8833@psf.upfronthosting.co.za>


New submission from Justin Bronder <jsbronder at gentoo.org>:

When adding hardlinks to an archive, tarfile does not set the size
of each additional link to zero as specified by the tar format [1].

In addition, the current test case hardlinks is also broken.
Instead of testing that the size of a hardlink to a non-empty file
is 0, it tests that the size to a empty file is zero, which cannot
fail.

A patch against current svn trunk is attached and was tested with
'python -m test.regrtest  -v test_tarfile'


1. http://www.gnu.org/software/tar/manual/tar.html#SEC170

----------
components: Library (Lib)
files: python-2.7-tarfile-hardlinks.patch
keywords: patch
messages: 106612
nosy: jsbronder
priority: normal
severity: normal
status: open
title: tarfile:  broken hardlink handling and testcase.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17474/python-2.7-tarfile-hardlinks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8833>
_______________________________________

From report at bugs.python.org  Thu May 27 18:28:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 27 May 2010 16:28:07 +0000
Subject: [issue8579] Add missing tests for FlushKey, LoadKey,
	and SaveKey in winreg
In-Reply-To: <1272650551.21.0.0191974450566.issue8579@psf.upfronthosting.co.za>
Message-ID: <1274977687.96.0.197330194515.issue8579@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

LoadKey and SaveKey require special privileges which need to manually acquired, likely via ctypes. #1578269 has some code which does this for os.symlink privileges and it's about to go into py3k, so I'll try to piggyback off of that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8579>
_______________________________________

From report at bugs.python.org  Thu May 27 18:36:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 16:36:28 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274978188.27.0.277260650244.issue8822@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8822>
_______________________________________

From report at bugs.python.org  Thu May 27 20:09:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 18:09:09 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274983749.17.0.480328978139.issue8822@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> 'naive' and 'aware' are key datetime types - they need a proper
> definition and anchor for crossrefences.

The definition is given in the introductory section:
"""
There are two kinds of date and time objects: ?naive? and ?aware?. This distinction refers to whether the object has any notion of time zone, daylight saving time, or other kind of algorithmic or political time adjustment. 
"""

I am not sure what you propose to add to this.  Do you wan't to dedicate a separate subsection to naive and aware time and datetime? I feel that would be an overkill.  Would simply adding index entries for naive and aware time/datetime objects be enough?

> It is not said how to make non-naive object, 

This may be due to the fact that there is no concrete tzinfo implementation in stdlib.  See issue 5094.

I think it can be added in datetime constructor section that providing a tzinfo argument results in an aware object.  this is already so for datetime.fromtimestamp.

> how to detect if object of naive or aware.

This is already clear IMO:

"""
An object d of type time or datetime may be naive or aware. d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None, d is naive.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8822>
_______________________________________

From report at bugs.python.org  Thu May 27 21:42:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 27 May 2010 19:42:31 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1274989351.85.0.818291945561.issue7171@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Thu May 27 22:46:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 20:46:21 +0000
Subject: [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This is a semi-serious feature request following a brief discussion on #python-dev IRC.

Brett Cannon pointed out on python-checkins list [1] that the names should be alphabetized.  However, given that the names are international, it is not obvious what it means.

I propose to add a comment at the top of Misc/ACKS that the list is maintained in "rough alphabetical order" but not define it any further.

[1] http://mail.python.org/pipermail/python-checkins/2010-May/093650.html

----------
assignee: docs at python
components: Documentation
messages: 106615
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Define order of Misc/ACKS entries
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8834>
_______________________________________

From report at bugs.python.org  Thu May 27 22:48:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 20:48:29 +0000
Subject: [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1274993309.56.0.616251151679.issue8834@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file17475/issue8834.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8834>
_______________________________________

From report at bugs.python.org  Thu May 27 23:02:07 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 27 May 2010 21:02:07 +0000
Subject: [issue8833] tarfile:  broken hardlink handling and testcase.
In-Reply-To: <1274976429.42.0.686584361847.issue8833@psf.upfronthosting.co.za>
Message-ID: <1274994127.35.0.509947150657.issue8833@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8833>
_______________________________________

From report at bugs.python.org  Thu May 27 23:44:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 21:44:48 +0000
Subject: [issue8598] test/support: don't use localhost as IPv6 host name
In-Reply-To: <1272794288.96.0.106540212417.issue8598@psf.upfronthosting.co.za>
Message-ID: <1274996688.88.0.798845038051.issue8598@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I consider that the bug is in my /etc/hosts configuration, not in Python. So I close the issue as "invalid".

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8598>
_______________________________________

From report at bugs.python.org  Thu May 27 23:47:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 21:47:37 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The nameserver responsible of sha2.hboeck.de is down and this hostname is used in test_ssl. The result is that all trunk buildbots are red (error).

support.transient_internet() should catch socket.gaierror.

--

One example: http://www.python.org/dev/buildbot/all/builders/amd64%20gentoo%20trunk/builds/1007

Traceback (most recent call last):
  File ".../Lib/test/test_ssl.py", line 261, in test_algorithms
    s.connect(remote)
  ...
gaierror: [Errno -2] Name or service not known

----------
components: Tests
messages: 106617
nosy: haypo
priority: normal
severity: normal
status: open
title: buildbot: support.transient_internet() doesn't catch DNS socket.gaierror
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Fri May 28 00:08:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 22:08:59 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1274998139.48.0.0249155495786.issue7150@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r81566 (trunk), r81568 (py3k), r81569 (release26-maint), r81570 (release31-maint).

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Fri May 28 00:19:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 22:19:49 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1274998789.79.0.395185728355.issue1289118@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> commit review
Added file: http://bugs.python.org/file17476/issue1289118-withdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Fri May 28 00:23:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 22:23:36 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1274999016.36.0.63741049231.issue8835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to catch gaierror(EAI_NODATA) and gaierror(EAI_NONAME).

----------
keywords: +patch
Added file: http://bugs.python.org/file17477/transilient_internet_dns.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Fri May 28 00:25:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 22:25:08 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1274999108.66.0.544971167964.issue8835@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Fri May 28 00:26:16 2010
From: report at bugs.python.org (Anthony Foglia)
Date: Thu, 27 May 2010 22:26:16 +0000
Subject: [issue8836] Conflicting default values of parameter to __import__
In-Reply-To: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>
Message-ID: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

Looking at the documentation for the __import__ builtin, the default value of the level parameter is unclear.  Two different values are mentioned.  The function signature is written:

__import__(name, globals={}, locals={}, fromlist=[], level=-1)

But the third paragraph begins: "level specifies whether to use absolute or relative imports. 0 (the default) means only perform absolute imports."

So which is it, -1 or 0?

I'm guessing 0.  If -1 is still a valid value, it needs to be described.

----------
assignee: docs at python
components: Documentation
messages: 106621
nosy: afoglia, docs at python
priority: normal
severity: normal
status: open
title: Conflicting default values of parameter to __import__
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8836>
_______________________________________

From report at bugs.python.org  Fri May 28 00:30:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 22:30:46 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1274999446.74.0.172364763658.issue8835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited the patch as r81571 in trunk. Wait for the buildbot before porting it to other branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Fri May 28 00:32:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 27 May 2010 22:32:50 +0000
Subject: [issue8836] Conflicting default values of parameter to __import__
In-Reply-To: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>
Message-ID: <1274999570.93.0.270829216463.issue8836@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81572.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8836>
_______________________________________

From report at bugs.python.org  Fri May 28 00:59:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 22:59:41 +0000
Subject: [issue8837] PyArg_ParseTuple(): remove old and unused "O?" format
In-Reply-To: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>
Message-ID: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"O?" format was introduced by r4301 (15 years, 9 months ago). PyArg_ParseTuple() was first documented in Python 2.2, but without the full list of all formats. The format list was added to Python 2.3, but "O?" was never documented. So I get that no third party progam use it.

In Python trunk, "O?" is no more used and so I propose to remove it to simplify getarg.c (simplify getarg cannot be a bad thing). PyArg_ParseTuple() has now better formats than "O?".

--

"O&" calls a callback: if the callback returns 0, raise an error; otherwise gets the object. Example of callbacks: PyXXX_Check() function (eg. PyInt_Check()).

--

The full Python test suite pass without any error on a patched Python (trunk).

----------
components: Interpreter Core
files: getarg_oquestion.patch
keywords: patch
messages: 106624
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple(): remove old and unused "O?" format
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17478/getarg_oquestion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8837>
_______________________________________

From report at bugs.python.org  Fri May 28 01:00:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:00:07 +0000
Subject: [issue8837] PyArg_ParseTuple(): remove old and unused "O?" format
In-Reply-To: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>
Message-ID: <1275001207.85.0.815176675047.issue8837@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8837>
_______________________________________

From report at bugs.python.org  Fri May 28 01:02:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:02:51 +0000
Subject: [issue8837] PyArg_ParseTuple(): remove old and unused "O?" format
In-Reply-To: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>
Message-ID: <1275001371.83.0.681368312058.issue8837@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8837>
_______________________________________

From report at bugs.python.org  Fri May 28 01:13:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:13:37 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

readbuffer_encode() and charbuffer_encode() are not really encoder nor related to encodings: they are related to PyBuffer. readbuffer_encode() uses "s#" format and charbuffer_encode() uses "t#" format to parse their arguments. Both functions were introduced by the creation of the _codecs module 10 years ago (r14660).

I think that these functions should be removed. memoryview() should be used instead.

Note: charbuffer_encode() is the last function using on of the "t" format (t, t#, t*) in Python3.

----------
components: Interpreter Core
messages: 106625
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 01:17:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:17:23 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275002243.61.0.79178239632.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A search in Google doesn't show anything interesting: it looks like these functions were never used outside Python test suite. I just noticed r41461: "Add tests for various error cases and for readbuffer_encode() and
charbuffer_encode(). This increases code coverage in Modules/_codecsmodule.c from 83% to 95%." (4 years ago)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 01:29:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2010 23:29:09 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"t#" format was introduced by r11803 (11 years ago): "Implement new format character 't#'. This is like s#, accepting an object that implements the buffer interface, but requires a buffer that contains 8-bit character data."

Python3 now has a strict separation between byte string (bytes and bytearray types) and unicode string (str), and has PyBuffer and PyCapsule APIs. "t#" format can be replaced by "y#" or "y*".

Extract of getarg.c:

      /*TEO: This can be eliminated --- here only for backward
        compatibility */
    case 't': { /* 8-bit character buffer, read-only access */

In Python, the last function using "t#" is _codecs.charbuffer_encode() and I proposed to remove this function in #8838. We can also patch this function.

I don't know if third party modules use this format or not. I don't know if it can be just removed or if it should raise a deprecation warning (but who will notice such warning since there are disabled by default?).

----------
components: Interpreter Core
messages: 106627
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple(): remove "t# format
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 01:36:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 23:36:22 +0000
Subject: [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1275003382.5.0.95661876265.issue8834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me.

----------
nosy: +pitrou
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8834>
_______________________________________

From report at bugs.python.org  Fri May 28 01:56:28 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 27 May 2010 23:56:28 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1275004588.63.0.703571437055.issue8825@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

I've opened a bug in the IronPython bug tracker: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=27209

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Fri May 28 02:12:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 May 2010 00:12:27 +0000
Subject: [issue8840] io.StringIO: truncate+print disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Some of my tests use io.StringIO and assert that captured print output equals expected output. Until now, I reused one buffer by truncating between tests. I recently replaced 3.1.1 with 3.1.2 (WinXP) and the *second* test of each run started failing. The following minimal code shows the problem (and should suggest a new unit test):

from io import StringIO; s = StringIO(); print(repr(s.getvalue()))
print('abc', file=s); print(repr(s.getvalue()))
s.truncate(0); print(repr(s.getvalue()))
print('abc', file=s); print(repr(s.getvalue()))

prints (both command window and IDLE)

''
'abc\n'
''
'\x00\x00\x00\x00abc\n' 
# should be and previously would have been 'abc\n'

s.truncate(0) zeros the buffer and appears to set the length to 0, but a subsequent print sees the length as what it was before the truncate and appends after the zeroed characters. Ugh.

I presume the problem is StringIO-emulation specific but have not tested 'real' files to be sure.

---
also...

>>> help(s.truncate)
Help on built-in function truncate:

truncate(...)
    Truncate size to pos.
...

should be, for greater clarity, something like

truncate([pos])
    Truncate the size of the file or buffer to pos
...

----------
components: IO, Library (Lib)
messages: 106630
nosy: tjreedy
priority: normal
severity: normal
stage: needs patch
status: open
title: io.StringIO: truncate+print disabled in 3.1.2
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Fri May 28 02:16:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 00:16:13 +0000
Subject: [issue8840] io.StringIO: truncate+print disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275005773.71.0.53609845475.issue8840@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This was an exceptional API change in 3.1.2: truncate() doesn't move the file pointer anymore, you have to do it yourself (with seek(0) in your case). I'm sorry for the inconvenience; the change was motivated by the desire of having an API more consistent with other file-handling APIs out there.

----------
nosy: +pakal, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Fri May 28 02:16:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 00:16:47 +0000
Subject: [issue8840] io.StringIO: truncate+print disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275005807.78.0.761665035181.issue8840@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Fri May 28 02:44:10 2010
From: report at bugs.python.org (Richard Lowe)
Date: Fri, 28 May 2010 00:44:10 +0000
Subject: [issue8841] GetoptError strings should be localized
In-Reply-To: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za>
Message-ID: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za>


New submission from Richard Lowe <richlowe at richlowe.net>:

The GetoptError exception raised by getopt.getopt() to indicate errors in provided arguments seems intended to be displayed to the user[1], but is not localized and doesn't contain enough information, short of interpreting the error string, for consumers to raise their own, localized, error.

[1] http://docs.python.org/library/getopt.html

----------
components: Library (Lib)
messages: 106632
nosy: richlowe
priority: normal
severity: normal
status: open
title: GetoptError strings should be localized
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8841>
_______________________________________

From report at bugs.python.org  Fri May 28 04:30:57 2010
From: report at bugs.python.org (Hari Krishna Dara)
Date: Fri, 28 May 2010 02:30:57 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1275013857.61.0.595714297968.issue672115@psf.upfronthosting.co.za>


Hari Krishna Dara <haridara at gmail.com> added the comment:

I just hit up on this same bug and the "class object(object): pass" workaround worked fine. I too would like to know how safe this workaround is, could someone more insightful please comment on this?

----------
nosy: +Hari.Krishna.Dara

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue672115>
_______________________________________

From report at bugs.python.org  Fri May 28 05:03:15 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Fri, 28 May 2010 03:03:15 +0000
Subject: [issue6583] 2to3 fails to fix test.test_support
In-Reply-To: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
Message-ID: <1275015795.9.0.0433709802029.issue6583@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

Pascal is correct, trunk Doc/library/test.rst still says: "The 2to3 tool will automatically adapt imports when converting your sources to 3.0." Perhaps this should simply be changed to "The 2to3 tool will not automatically convert this, so make sure you do, manually, if you port your code to Python 3."

Please let me know if you require a patch for this (but I think it's trivial enough), or if you think this should raise a -3 warning.

----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6583>
_______________________________________

From report at bugs.python.org  Fri May 28 05:11:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 May 2010 03:11:57 +0000
Subject: [issue6583] 2to3 fails to fix test.test_support
In-Reply-To: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
Message-ID: <1275016317.66.0.467950190848.issue6583@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r81579

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6583>
_______________________________________

From report at bugs.python.org  Fri May 28 06:14:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 04:14:26 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1275020066.79.0.688488991402.issue2394@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Fri May 28 06:46:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 04:46:47 +0000
Subject: [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1275022007.27.0.197724679583.issue4653@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't run Windows either but I believe sizeof(char) == 1 is guaranteed by the C standard, so the first report (Python/dynload_win.c) is invalid.

The last two appear to be valid [1], and a common mistake. [2]  Unit tests are needed for these.  I also notice that r81156 does not add a unit test either.  ISTM, a test case can be crafted by setting sys.stderr to None.

[1] http://msdn.microsoft.com/en-us/library/aa366537(VS.85).aspx
[2] http://blogs.msdn.com/b/oldnewthing/archive/2004/03/02/82639.aspx

----------
components: +Windows
nosy: +belopolsky
stage: commit review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Fri May 28 07:03:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 05:03:51 +0000
Subject: [issue4653] Patch to fix typos for Py3K
In-Reply-To: <1229155016.15.0.221157622828.issue4653@psf.upfronthosting.co.za>
Message-ID: <1275023031.83.0.0746940811909.issue4653@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Strike my comment about Python/dynload_win.c - I was looking at the trunk version instead of py3k.  In py3k theInfo is wchar_t and patch seems to be valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4653>
_______________________________________

From report at bugs.python.org  Fri May 28 07:14:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 05:14:49 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1275023689.2.0.975570651659.issue2651@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Fri May 28 07:16:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 05:16:04 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1275023764.6.0.329280455819.issue2651@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Fri May 28 07:21:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 05:21:04 +0000
Subject: [issue2920] Patch to print symbolic value or errno in
	EnvironmentError.__str__()
In-Reply-To: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za>
Message-ID: <1275024064.09.0.86759980297.issue2920@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2920>
_______________________________________

From report at bugs.python.org  Fri May 28 07:25:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 05:25:14 +0000
Subject: [issue762920] API Functions for PyArray
Message-ID: <1275024314.28.0.285994016957.issue762920@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is there still any interest in pursuing this?  Raymond?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762920>
_______________________________________

From report at bugs.python.org  Fri May 28 07:32:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 05:32:53 +0000
Subject: [issue3196] Option in pydoc to show docs from private methods
In-Reply-To: <1214386355.64.0.670337337662.issue3196@psf.upfronthosting.co.za>
Message-ID: <1275024773.33.0.21418751425.issue3196@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3196>
_______________________________________

From report at bugs.python.org  Fri May 28 09:17:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 May 2010 07:17:35 +0000
Subject: [issue8825] int("0",0) throws exception
In-Reply-To: <1274895861.73.0.0531929444904.issue8825@psf.upfronthosting.co.za>
Message-ID: <1275031055.39.0.615296684033.issue8825@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Dino:  I think Clark already did this:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=27186

Sorry;  I checked that there was an IronPython issue open before I closed this one, but forgot to mention it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8825>
_______________________________________

From report at bugs.python.org  Fri May 28 09:54:18 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 07:54:18 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <4BFF76A6.3090403@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> readbuffer_encode() and charbuffer_encode() are not really encoder nor related to encodings: they are related to PyBuffer. readbuffer_encode() uses "s#" format and charbuffer_encode() uses "t#" format to parse their arguments. Both functions were introduced by the creation of the _codecs module 10 years ago (r14660).
> 
> I think that these functions should be removed. memoryview() should be used instead.
> 
> Note: charbuffer_encode() is the last function using on of the "t" format (t, t#, t*) in Python3.

Those two encoder functions were meant to be used by Python codec
implementations which want to use the readbuffer and charbuffer
interfaces available in Python via "s#" and "t#" to access input
object data.

They are not used by the builtin codecs, but may well be in use
by 3rd party codecs.

I'm not sure why you think those functions are not encoders.

----------
nosy: +lemburg
title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 10:14:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 08:14:57 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <4BFF7B6E.3030804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> "t#" format was introduced by r11803 (11 years ago): "Implement new format character 't#'. This is like s#, accepting an object that implements the buffer interface, but requires a buffer that contains 8-bit character data."
> 
> Python3 now has a strict separation between byte string (bytes and bytearray types) and unicode string (str), and has PyBuffer and PyCapsule APIs. "t#" format can be replaced by "y#" or "y*".
>
> Extract of getarg.c:
> 
>       /*TEO: This can be eliminated --- here only for backward
>         compatibility */
>     case 't': { /* 8-bit character buffer, read-only access */
> 
> In Python, the last function using "t#" is _codecs.charbuffer_encode() and I proposed to remove this function in #8838. We can also patch this function.
> 
> I don't know if third party modules use this format or not. I don't know if it can be just removed or if it should raise a deprecation warning (but who will notice such warning since there are disabled by default?).

Since Python3 completely removed the getcharbuffer interface
to which the "t#" interfaces in Python2, "t#" does indeed no
longer serve any special purpose.

It's probably wise to just map "t#" to "y#" in order to ease
porting extensions from 2.x to 3.x.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 12:33:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 10:33:32 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1275042812.66.0.601109251023.issue8839@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to remove "t#":
 - Update c-api/arg.rst documentation
 - Replace "t#" format by "y#" in codecs.charbuffer_encode()
 - Add a note in Doc/whatsnew/3.2.rst (in Porting to Python 3.2)

----------
keywords: +patch
Added file: http://bugs.python.org/file17479/getarg_remove_tdash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 12:39:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 10:39:53 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275042812.66.0.601109251023.issue8839@psf.upfronthosting.co.za>
Message-ID: <4BFF9D75.3080608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Patch to remove "t#":
>  - Update c-api/arg.rst documentation
>  - Replace "t#" format by "y#" in codecs.charbuffer_encode()
>  - Add a note in Doc/whatsnew/3.2.rst (in Porting to Python 3.2)

Given that "y#" is not (yet) in wide-spread use, it may actually make
more sense, to replace "y#" with "t#" and introduce "t*" to replace
"y*".

"y#" and "y*" could then be setup as synonyms for "t#" and "t*".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 13:04:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 11:04:02 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1275044642.5.0.15082943935.issue8839@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Given that "y#" is not (yet) in wide-spread use, ...

t# is only used once (in codecs.charbuffer_encode()), whereas y# is used by ossaudiodev, socket and mmap modules (there are 8 functions using y#). There are 46 functions using y* format. y format is not used in Python3.

To me, it looks easier to just drop t# and continue to use y, y* and y# formats in Python3.

> "y#" and "y*" could then be setup as synonyms for "t#" and "t*"

If we have to keep backward compatibility, yes, t# can be kept as a synonym for y#. But I don't think that backward compatibility of the C API is important in Python3 because only few 3rd party modules are compatible with Python3.

--

I prefer to use y, y* and y# formats because they target the *bytes* type (which is the Python3 type to store byte strings), whereas s# is used in Python2 to get text, *str* type.. which are byte strings, but most Python2 programmers consider that the str type is the type of chararacter string. I see the change of s# to y#, as the change from str to bytes (the strict separation between bytes and str).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 13:14:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 11:14:58 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275045298.05.0.722649960636.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Those two encoder functions were meant to be used by Python codec
> implementations which want to use the readbuffer and charbuffer
> interfaces available in Python via "s#" and "t#" to access input
> object data.

Ah ok.

> They are not used by the builtin codecs, 
> but may well be in use by 3rd party codecs.

My quick Google search didn't found any of those. I suppose that str and bytes are enough for most people. Do you know an usecase of text or bytes stored in different types than str and bytes? (I suppose the bytearray is compatible with bytes, and so it can be used instead of bytes)

> I'm not sure why you think those functions are not encoders.

I consider that Python3 codecs module only encode and decode text to/from an encoding, whereas Python2 had extra unrelated codecs like "base64" or "hex" (but it was decided to remove them to cleanup the codecs module).

----------
title: Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 13:21:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 11:21:48 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1275045708.75.0.802108165077.issue8835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There is another error:

test test_ssl failed -- Traceback (most recent call last):
  File "/scratch/pybot-buildarea/trunk.klose-ubuntu-i386/build/Lib/test/test_ssl.py", line 261, in test_algorithms
    s.connect(remote)
  File "/scratch/pybot-buildarea/trunk.klose-ubuntu-i386/build/Lib/ssl.py", line 292, in connect
    socket.connect(self, addr)
  File "/scratch/pybot-buildarea/trunk.klose-ubuntu-i386/build/Lib/socket.py", line 222, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 110] Connection timed out

transient_internet() should also catch socket.error(errno.ETIMEDOUT).

--

See also #8455, #8499 and #8574.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Fri May 28 13:24:08 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 28 May 2010 11:24:08 +0000
Subject: [issue8842] sqlite3 library outdated in Windows builds
In-Reply-To: <1275045847.96.0.603082208201.issue8842@psf.upfronthosting.co.za>
Message-ID: <1275045847.96.0.603082208201.issue8842@psf.upfronthosting.co.za>


New submission from Marko Kohtala <marko.kohtala at gmail.com>:

The Windows builds seem to come with SQLite library version 3.5.9, as seen from sqlite3.sqlite_version. This is from 2008-May-12.

I've been using the sqlite3 module, but keep running into bugs on Windows. Replacing the DLLs\sqlite3.dll with a newer library (sqlite is going at version 3.6.23), seems to fix those problems.

One problem was locking failures when performing a lot of changes and committing after each change. This happens within a single script accessing the file, apparently locking himself out. I did not want users needing to patch installed Python, so I got around that by removing the smaller commits and making one huge commit at end.

Now I had a problem that ANALYZE does not result in good queries. Performing ANALYZE with newer library speeded queries significantly. I do not know how to get around that.

On Linux I see Python 2.6 using sqlite 3.6.x versions, so I'd expect the reason for old library on Windows can not be incompatibility.

----------
components: Library (Lib), Windows
messages: 106647
nosy: Marko.Kohtala
priority: normal
severity: normal
status: open
title: sqlite3 library outdated in Windows builds
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8842>
_______________________________________

From report at bugs.python.org  Fri May 28 13:30:21 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 11:30:21 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275044642.5.0.15082943935.issue8839@psf.upfronthosting.co.za>
Message-ID: <4BFFA949.2000405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Given that "y#" is not (yet) in wide-spread use, ...
> 
> t# is only used once (in codecs.charbuffer_encode()), whereas y# is used by ossaudiodev, socket and mmap modules (there are 8 functions using y#). There are 46 functions using y* format. y format is not used in Python3.
> 
> To me, it looks easier to just drop t# and continue to use y, y* and y# formats in Python3.

You are forgetting our main target: to get extension writers to
port their extensions to Python3. Changes to the Python core are
a lot easier to implement than getting thousands of extensions
ported.

"t#" is in wide-spread use, since it's the only way a Python2
extension can request access to an object's text data version.

"y#" was introduced with Python3, and there are only very few
extensions written for it.

Given these facts, it's better to drop "y#" and replace it with
"t#". This is easily done for the core modules and by adding
synonyms for "y#" we can also automatically take care of the
few Python3 extensions possibly using it.

>> "y#" and "y*" could then be setup as synonyms for "t#" and "t*"
> 
> If we have to keep backward compatibility, yes, t# can be kept as a synonym for y#. But I don't think that backward compatibility of the C API is important in Python3 because only few 3rd party modules are compatible with Python3.

True and that's why we have to make it easier for extension writer
to port their extensions rather than making it harder.

It is not too difficult to adjust a Python2 extension to work
in Python3 as well, so that's most likely the route that
many extension writer will take, hence the need to reduce the
number of differences between the Python2 and Python3 C API.

> --
> 
> I prefer to use y, y* and y# formats because they target the *bytes* type (which is the Python3 type to store byte strings), whereas s# is used in Python2 to get text, *str* type.. which are byte strings, but most Python2 programmers consider that the str type is the type of chararacter string. I see the change of s# to y#, as the change from str to bytes (the strict separation between bytes and str).

That's not correct: "s#" is used in Python2 to get at the bytes
representation of an object, not the text version. "t#" was
specifically added to access a text version of the content.

In Python3, this distinction is no longer available (for whatever
reason), so only the bytes representation of the object remains.

Looking at the implementation again, I found that "y#" rejects
Unicode, while "s#" returns the default encoded version like
"t#" does in Python2.

So I have to correct what I said earlier:

"y#" is not the right replacement for "t#" in order to stay compatible
with its Python2 pendant. The "t#" implementation in Python3 is not
compatible with the Python2 approach - it's in fact, a totally
different parser, since Unicode no longer provides a buffer interface
and thus cannot be used as input for "t#".

The only compatible pendant to the Python2 "t#" parser marker
in Python3 appears to be "s#".

I'll have to think about this some more, but seen in that light,
removing "t#" in Python3 may actually be a better strategy after
all - mostly to remove a misguided forward-porting attempt
and to reduce the number of surprising extension writer will
see when porting their apps to Python3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 13:33:19 2010
From: report at bugs.python.org (Andrew Nelis)
Date: Fri, 28 May 2010 11:33:19 +0000
Subject: [issue8843] urllib2 Digest Authorization uri must match request URI
In-Reply-To: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za>
Message-ID: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za>


New submission from Andrew Nelis <andrew.nelis at gmail.com>:

When using Digest authentication to authenticate with a web server, according to rfc2617 (section 3.2.2.5) the uri in the Authorization header MUST match the request URI.

urllib2.AbstractDigestAuthHandler doesn't honour this when we request a url of the form 'http://hostname' without the trailing slash and we end up with request headers of the form:

GET / 1.1
...
Authorization: Digest ... uri="" <- should be uri="/"!

A web server will return 400 Bad Request error.

I attach a patch to fix urllib2.AbstractDigestAuthHandler.get_authorization that simply checks for the empty uri and uses '/' instead. It's the same thing that httplib.HTTPConnection does when it builds the GET line.

However I do wonder if this uri normalisation should be part of Request.get_selector?

Following is a script to demonstrate the behaviour, if you call it as:

./do_digest_request.py http://myserver username password

(and assuming myserver is using Digest authentication) there will a 400 response instead of it working.

--- do_digest_request.py
#!/usr/bin/env python

import sys
import urllib2
import urlparse

def request( url, username, password ):

    p = urlparse.urlparse( url )
    password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm()
    password_manager.add_password( None, p.hostname, username, password )

    handlers = [
        urllib2.HTTPDigestAuthHandler( password_manager ),
    ]

    opener = urllib2.build_opener( *handlers )
    request = urllib2.Request( url )
    response = opener.open( request )
    response.read()


if __name__ == '__main__':
    request( sys.argv[1], sys.argv[2], sys.argv[3] )

----------
components: Library (Lib)
files: urllib2.diff
keywords: patch
messages: 106649
nosy: anelis
priority: normal
severity: normal
status: open
title: urllib2 Digest Authorization uri must match request URI
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17480/urllib2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8843>
_______________________________________

From report at bugs.python.org  Fri May 28 13:35:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 11:35:26 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275045298.05.0.722649960636.issue8838@psf.upfronthosting.co.za>
Message-ID: <4BFFAA7B.3070003@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> Those two encoder functions were meant to be used by Python codec
>> implementations which want to use the readbuffer and charbuffer
>> interfaces available in Python via "s#" and "t#" to access input
>> object data.
> 
> Ah ok.
> 
>> They are not used by the builtin codecs, 
>> but may well be in use by 3rd party codecs.
> 
> My quick Google search didn't found any of those. I suppose that str and bytes are enough for most people. Do you know an usecase of text or bytes stored in different types than str and bytes? (I suppose the bytearray is compatible with bytes, and so it can be used instead of bytes)

Any Python object can expose a buffer interface and the above
functions then allow accessing these interfaces from within
Python.

Think of e.g. memory mapped files, image/audio/video objects,
database BLOBs, scientific data types, numeric arrays, etc.
There are lots of such object types.

>> I'm not sure why you think those functions are not encoders.
> 
> I consider that Python3 codecs module only encode and decode text to/from an encoding, whereas Python2 had extra unrelated codecs like "base64" or "hex" (but it was decided to remove them to cleanup the codecs module).

Those codecs will be reenabled in Python 3.2. Removing them was
a mistake. The codec machinery is not limited to only working
on Unicode and bytes. It can work on arbitrary type combinations,
depending on what a codec wants to implement.

----------
title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 14:06:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 May 2010 12:06:12 +0000
Subject: [issue2920] Patch to print symbolic value or errno in
	EnvironmentError.__str__()
In-Reply-To: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za>
Message-ID: <1275048372.25.0.526805611833.issue2920@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't like the "import errno" while printing an exception...
It would be much more robust to store errorcode_dict in a static variable when python starts, and reuse it directly.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2920>
_______________________________________

From report at bugs.python.org  Fri May 28 14:08:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 12:08:48 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <4BFFA949.2000405@egenix.com>
Message-ID: <201005281408.39827.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 28 mai 2010 13:30:22, vous avez ?crit :
> Looking at the implementation again, I found that "y#" rejects
> Unicode, while "s#" returns the default encoded version like
> "t#" does in Python2.

Oh, I didn't noticed that.

> So I have to correct what I said earlier:
> 
> "y#" is not the right replacement for "t#" in order to stay compatible
> with its Python2 pendant. The "t#" implementation in Python3 is not
> compatible with the Python2 approach - it's in fact, a totally
> different parser, since Unicode no longer provides a buffer interface
> and thus cannot be used as input for "t#".
> 
> The only compatible pendant to the Python2 "t#" parser marker
> in Python3 appears to be "s#".
> 
> I'll have to think about this some more, but seen in that light,
> removing "t#" in Python3 may actually be a better strategy after
> all - mostly to remove a misguided forward-porting attempt
> and to reduce the number of surprising extension writer will
> see when porting their apps to Python3.

So t#, s# and y# are all different. I'm waiting for your final decision.

"reduce the number of surprising extension writer ..." is a good argument in 
favor of removing t# :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 14:19:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 12:19:21 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275049161.52.0.624177189189.issue8838@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Any Python object can expose a buffer interface and the above
> functions then allow accessing these interfaces from within
> Python.

What's the point? The codecs functions already support objects exposing the buffer interface:

>>> b = b"\xe9"
>>> codecs.latin_1_decode(memoryview(b))
('?', 1)
>>> codecs.latin_1_decode(array.array("b", b))
('?', 1)

Those two functions are undocumented. They serve no useful purpose (you can call the bytes(...) constructor instead, or even use the buffer object directly as showed above). They are badly named since they don't have anything to do with codecs. Google Code Search shows them not appearing anywhere else than implementations of the Python stdlib. Removing them only seems reasonable.

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 14:27:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 12:27:33 +0000
Subject: [issue2920] Patch to print symbolic value or errno in
	EnvironmentError.__str__()
In-Reply-To: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za>
Message-ID: <1275049653.85.0.964764925879.issue2920@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Amaury. Module import could fail for various reasons (perhaps the same ones which led to the exception being raised!), or could deadlock if the import lock is being held. Also, having __str__ fail is usually very annoying for users (especially when it's the __str__ of an exception object).

If it's too hard to import errno at startup (because of bootstrapping), I would suggest using PyImport_ImportModuleNoBlock() instead, and silence errors (just print the numeric value of errno instead).

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2920>
_______________________________________

From report at bugs.python.org  Fri May 28 14:38:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 May 2010 12:38:39 +0000
Subject: [issue2920] Patch to print symbolic value or errno in
	EnvironmentError.__str__()
In-Reply-To: <1275049653.85.0.964764925879.issue2920@psf.upfronthosting.co.za>
Message-ID: <E118D98E-9187-482B-B5B2-E8AA9B8A1888@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The patch already checks for failed import and falls back to printing  
numerical error code. However, I don't like the import either. I will  
think about the alternatives.

On May 28, 2010, at 8:27 AM, Antoine Pitrou <report at bugs.python.org>  
wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Agreed with Amaury. Module import could fail for various reasons  
> (perhaps the same ones which led to the exception being raised!), or  
> could deadlock if the import lock is being held. Also, having  
> __str__ fail is usually very annoying for users (especially when  
> it's the __str__ of an exception object).
>
> If it's too hard to import errno at startup (because of  
> bootstrapping), I would suggest using PyImport_ImportModuleNoBlock()  
> instead, and silence errors (just print the numeric value of errno  
> instead).
>
> ----------
> nosy: +pitrou
> versions: +Python 2.7, Python 3.1, Python 3.2
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2920>
> _______________________________________

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2920>
_______________________________________

From report at bugs.python.org  Fri May 28 14:39:41 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 12:39:41 +0000
Subject: [issue8838] Remove
	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275049161.52.0.624177189189.issue8838@psf.upfronthosting.co.za>
Message-ID: <4BFFB98A.9060907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Any Python object can expose a buffer interface and the above
>> functions then allow accessing these interfaces from within
>> Python.
> 
> What's the point? The codecs functions already support objects exposing the buffer interface:
> 
>>>> b = b"\xe9"
>>>> codecs.latin_1_decode(memoryview(b))
> ('?', 1)
>>>> codecs.latin_1_decode(array.array("b", b))
> ('?', 1)
>
> Those two functions are undocumented. They serve no useful purpose (you can call the bytes(...) constructor instead, or even use the buffer object directly as showed above). They are badly named since they don't have anything to do with codecs. Google Code Search shows them not appearing anywhere else than implementations of the Python stdlib. Removing them only seems reasonable.

readbuffer_encode and charbuffer_encode convert objects to bytes
and provide a codec encoder interface for this, hence the naming.

They are meant to be used as encode methods for codecs, just like
the other *_encode functions exposed in the _codecs module, e.g.

class BinaryDataCodec(codecs.Codec):

    # Note: Binding these as C functions will result in the class not
    # converting them to methods. This is intended.
    encode = codecs.readbuffer_encode
    decode = codecs.latin_1_decode

While it's possible to emulate the functions via other methods,
these methods always introduce intermediate objects, which isn't
necessary and only costs performance.

Given than "t#" was basically rendered useless in Python3 (see
issue8839), removing charbuffer_encode() is indeed possible,
so

+1 on removing charbuffer_encode()
-1 on removing readbuffer_encode()

----------
title: Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 14:45:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 May 2010 12:45:27 +0000
Subject: [issue8838] Remove
	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275050727.0.0.493321483717.issue8838@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d be grateful if someone could post links to discussion about the removal of codecs like hex and rot13 and about their coming back. It may be useful for a NEWS entry too, not just for my personal curiosity ;) I?ll try to find them next week or so if nobody posts them before. Thanks.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:02:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 13:02:23 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()	and
	codecs.charbuffer_encode()
In-Reply-To: <4BFFB98A.9060907@egenix.com>
Message-ID: <1275051738.3101.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> class BinaryDataCodec(codecs.Codec):
> 
>     # Note: Binding these as C functions will result in the class not
>     # converting them to methods. This is intended.
>     encode = codecs.readbuffer_encode
>     decode = codecs.latin_1_decode

What's the point, though? Creating a non-symmetrical codec doesn't sound
like a very useful or recommandable thing to do. Especially in the py3k
codec model where encode() only works on unicode objects.

> While it's possible to emulate the functions via other methods,
> these methods always introduce intermediate objects, which isn't
> necessary and only costs performance.

The bytes() constructor doesn't (shouldn't) create any more intermediate
objects than read/charbuffer_encode() do.

And all this doesn't address the fact that these functions have never
been documented, and don't seem used in the outside world
(understandably so, since there's no way to know about their existence,
and their intended use).

----------
title: Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:09:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:09:59 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()	and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275052199.1.0.15408807375.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I?d be grateful if someone could post links to discussion
> about the removal of codecs like hex and rot13

r55932 (~3 years ago):

"Rip out all codecs that can't work in a unicode/bytes world:
base64, uu, zlib, rot_13, hex, quopri, bz2, string_escape.

However codecs.escape_encode() and codecs.escape_decode()
still exist, as they are used for pickling str8 objects
(so those two functions can go, when the str8 type is removed)."

There were removed 1 year and an half before Python 3.0 release.

> ... and about their coming back

which coming back?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:12:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 May 2010 13:12:06 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275052199.1.0.15408807375.issue8838@psf.upfronthosting.co.za>
Message-ID: <4BFFC123.2070702@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the link. Do you have a pointer to the PEP or ML thread
discussing that change?

?Which coming back??
Martin said these codecs are coming back in 3.2.

----------
title: Remove codecs.readbuffer_encode()	and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:17:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 13:17:23 +0000
Subject: [issue8843] urllib2 Digest Authorization uri must match request URI
In-Reply-To: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za>
Message-ID: <1275052644.0.0.714828721283.issue8843@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> orsenthil
nosy: +orsenthil
stage:  -> patch review
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8843>
_______________________________________

From report at bugs.python.org  Fri May 28 15:18:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 13:18:02 +0000
Subject: [issue8839] PyArg_ParseTuple(): remove "t# format
In-Reply-To: <1275002949.14.0.769648340098.issue8839@psf.upfronthosting.co.za>
Message-ID: <1275052682.98.0.202915583914.issue8839@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8839>
_______________________________________

From report at bugs.python.org  Fri May 28 15:18:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:18:44 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275052724.69.0.178165398856.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Martin said these codecs are coming back in 3.2.

Oh, there is the issue #7485 where Martin wrote:
* 2009-12-10 23:15: "It was a mistake that they were integrated"
* 2009-12-12 19:25: "I would still be opposed to such a change (...) adding them would be really confusing."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:18:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:18:57 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1275052737.23.0.705070457935.issue7475@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Fri May 28 15:20:52 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 28 May 2010 13:20:52 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275052852.25.0.995883064447.issue8838@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

> > I?d be grateful if someone could post links to discussion
> > about the removal of codecs like hex and rot13
> r55932 (~3 years ago):

That was my commit. ;)

> Thanks for the link. Do you have a pointer to the PEP or ML thread
> discussing that change?

The removal is documented here: http://www.artima.com/weblogs/viewpost.jsp?thread=208549

"""
We are adopting a slightly different approach to codecs: while in Python 2, codecs can accept either Unicode or 8-bits as input and produce either as output, in Py3k, encoding is always a translation from a Unicode (text) string to an array of bytes, and decoding always goes the opposite direction. This means that we had to drop a few codecs that don't fit in this model, for example rot13, base64 and bz2 (those conversions are still supported, just not through the encode/decode API).
"""

A post by Georg Brandl about this is at http://mail.python.org/pipermail/python-3000/2007-June/008420.html

(Note that this thread began in private email between Guido, MvL, Georg and myself. If needed I can dig up the emails.)

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:23:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:23:19 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275052999.91.0.891973196382.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Oh, there is the issue #7485 where Martin wrote:

Copy/paste failure: issue #7475.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:23:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 13:23:31 +0000
Subject: [issue8838] Remove
	codecs.readbuffer_encode()	and	codecs.charbuffer_encode()
In-Reply-To: <1275051738.3101.7.camel@localhost.localdomain>
Message-ID: <4BFFC3CF.8090406@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> class BinaryDataCodec(codecs.Codec):
>>
>>     # Note: Binding these as C functions will result in the class not
>>     # converting them to methods. This is intended.
>>     encode = codecs.readbuffer_encode
>>     decode = codecs.latin_1_decode
> 
> What's the point, though? Creating a non-symmetrical codec doesn't sound
> like a very useful or recommandable thing to do. 

Why not ? If you're only interested in the binary data and
don't care about the original input object type, that's a
very natural thing to do.

E.g. you could use a memory mapped file as input to the encoder.
Would you really expect the codec to recreate such a file object when
decoding the binary data ?

> Especially in the py3k
> codec model where encode() only works on unicode objects.

That's a common misunderstanding. The codec system does not
mandate a specific type combination. Only the helper methods
.encode() and .decode() on bytes and str objects in Python3 do.

>> While it's possible to emulate the functions via other methods,
>> these methods always introduce intermediate objects, which isn't
>> necessary and only costs performance.
> 
> The bytes() constructor doesn't (shouldn't) create any more intermediate
> objects than read/charbuffer_encode() do.

Looking at the code, the data takes quite a long path through
the whole machinery. For non-Unicode objects, it always tries to create
an integer and only if that fails reverts back to the buffer
interface after a few more function calls.

Furthermore, the bytes() constructor accepts a lot more
objects than the "s#" parser marker, e.g. lists of integers,
plain integers, arbitrary iterators, which a codec
just interested in the binary representation of an
object via the buffer interface most likely doesn't
want to accept.

> And all this doesn't address the fact that these functions have never
> been documented, and don't seem used in the outside world
> (understandably so, since there's no way to know about their existence,
> and their intended use).

That's a documentation bug and probably the result of the fact
that none of the exposed encoder/decoder APIs are documented.

----------
title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:25:58 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 13:25:58 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275052724.69.0.178165398856.issue8838@psf.upfronthosting.co.za>
Message-ID: <4BFFC452.9060704@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
>> Martin said these codecs are coming back in 3.2.

I said that and it was discussed on the python-dev mailing list
a while back.

We'll also add .transform() methods on bytes and str objects
to access same-type codecs.

----------
title: Remove codecs.readbuffer_encode()	and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:33:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:33:43 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275053623.06.0.452501607935.issue8838@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> readbuffer_encode() and charbuffer_encode() are not really encoder 
> nor related to encodings: they are related to PyBuffer

That was the initial problem: codecs is specific to encodings (in Python3), encodes str to bytes, and decodes bytes (or any read buffer) to str.

I don't like readbuffer_*encode* and *charbuffer_encode*  function names, because there are different than other codecs: they encode *bytes* to bytes (and not str to bytes). I think that these functions should be removed or moved somewhere else under a different name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:35:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 13:35:02 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()	and
	codecs.charbuffer_encode()
In-Reply-To: <4BFFC3CF.8090406@egenix.com>
Message-ID: <1275053698.3101.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > And all this doesn't address the fact that these functions have never
> > been documented, and don't seem used in the outside world
> > (understandably so, since there's no way to know about their existence,
> > and their intended use).
> 
> That's a documentation bug and probably the result of the fact
> that none of the exposed encoder/decoder APIs are documented.

Are you planning to fix it? It is not obvious anybody else is able to
properly document those functions.

----------
title: Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode()	and codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:35:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 28 May 2010 13:35:59 +0000
Subject: [issue8842] sqlite3 library outdated in Windows builds
In-Reply-To: <1275045847.96.0.603082208201.issue8842@psf.upfronthosting.co.za>
Message-ID: <1275053759.13.0.95873584538.issue8842@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

SQLite was upgraded to 3.6.21 about 4 months ago for 2.7 and 3.2.

----------
nosy: +brian.curtin
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8842>
_______________________________________

From report at bugs.python.org  Fri May 28 15:45:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:45:59 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1275054359.5.0.498273872537.issue7475@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I agree with Martin: codecs choosed the wrong direction in Python2, and it's fixed in Python3. The codecs module is related to charsets (encodings), should encode str to bytes, and should decode bytes (or any read buffer) to str.

Eg. rot13 "encodes" str to str.

"base64 bz2 hex zlib ...": use base64, bz2, binascii and zlib modules for that.

The documentation should be fixed (explain how to port code from Python2 to Python3).

It's maybe possible for write some 2to3 fixers for the following examples:

"...".encode("base64") => base64.b64encode("...")
"...".encode("rot13") => do nothing (but display a warning?)
"...".encode("zlib") => zlib.compress("...")
"...".encode("hex") => base64.b16encode("...")
"...".encode("bz2") => bz2.compress("...")

"...".decode("base64") => base64.b64decode("...")
"...".decode("rot13") => do nothing (but display a warning?)
"...".decode("zlib") => zlib.decompress("...")
"...".decode("hex") => base64.b16decode("...")
"...".decode("bz2") => bz2.decompress("...")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Fri May 28 15:48:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 13:48:56 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1275054536.57.0.357721920168.issue7475@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Explanation the change in Python3 by Guido:

"We are adopting a slightly different approach to codecs: while in Python 2, codecs can accept either Unicode or 8-bits as input and produce either as output, in Py3k, encoding is always a translation from a Unicode (text) string to an array of bytes, and decoding always goes the opposite direction. This means that we had to drop a few codecs that don't fit in this model, for example rot13, base64 and bz2 (those conversions are still supported, just not through the encode/decode API)."

http://www.artima.com/weblogs/viewpost.jsp?thread=208549

--

See also issue #8838.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Fri May 28 15:52:04 2010
From: report at bugs.python.org (Per)
Date: Fri, 28 May 2010 13:52:04 +0000
Subject: [issue4015] [patch] make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1275054724.93.0.37330555006.issue4015@psf.upfronthosting.co.za>


Per <pybugs.phobie at safersignup.com> added the comment:

On POSIX the interpreter will be read from the first line of a file.
On Windows the interpreter will be read from the Registry HKEY_CLASSES_ROOT\.<file-extension> .

So the correct way to associate a interpreter to a file is to invent a file-extension for every interpreter.
Like /usr/bin/python /usr/bin/python3 and /usr/bin/python3.1 on POSIX, there should be .py .py3 and .py31 on Windows!

I attached a example-registry-patch to register extensions for 2.5, 2.6 and 3.1 .
If you want to use it, you need to adjust the paths!

I propose to change all Python-Windows-installer to install versioned extensions.

If you want a switcher application, it should read the first line of the script and match it against ".*/python(.*)$". So the default POSIX "#!/usr/bin/python3.1" can be kept unchanged. With that rexex the app-path can be read from "HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\<regex-match>\InstallPath\".

BTW.
It would be nice if Python would call itself "Python 3.1" instead of "python" in the "Open with..."-list! The current naming is problematic if you install more than one Python version.

----------
nosy: +phobie
Added file: http://bugs.python.org/file17481/hklm_python_extensions.reg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri May 28 15:52:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 May 2010 13:52:37 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode() and
	codecs.charbuffer_encode()
In-Reply-To: <1275002017.75.0.302568685323.issue8838@psf.upfronthosting.co.za>
Message-ID: <1275054757.49.0.712508962734.issue8838@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I don't like readbuffer_*encode* and *charbuffer_encode*
> function names, because there are different than other codecs
?transform? as hinted by MvL seems perfect.

Thanks everyone for the pointers here and in #7475! I?ll search the missing one (?it was discussed on the python-dev mailing list a while back?) later.

----------
title: Remove codecs.readbuffer_encode()	and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Fri May 28 15:58:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 May 2010 13:58:12 +0000
Subject: [issue4015] [patch] make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1275055092.94.0.0971598570439.issue4015@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Related to #870479 (should we make that one a meta-bug?)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri May 28 16:17:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 28 May 2010 14:17:53 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1275054359.5.0.498273872537.issue7475@psf.upfronthosting.co.za>
Message-ID: <4BFFD08E.5060700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> I agree with Martin: codecs choosed the wrong direction in Python2, and it's fixed in Python3. The codecs module is related to charsets (encodings), should encode str to bytes, and should decode bytes (or any read buffer) to str.

No, that's just not right: the codec system in Python does not
mandate the types used or accepted by the codecs.

The only change that was applied in Python3 was to make sure
that the str.encode() and bytes.decode() methods always return
the same type to assure type-safety.

Python2 does not apply that check, but instead provides a
direct interface to codecs.encode() and codecs.decode().

Please don't mix the helper methods on those objects with what
the codec system was designed for. The helper methods apply
a strategy that's more constrained than the codec system.

The addition of .transform() and .untransform() for same
type conversions was discussed in 2008, but didn't make it into 3.0
since I hadn't had time to add the methods:

http://mail.python.org/pipermail/python-3000/2008-August/014533.html
http://mail.python.org/pipermail/python-3000/2008-August/014533.html
http://mail.python.org/pipermail/python-3000/2008-August/014534.html

The removed codecs don't rely on the helper methods in any way.
They are easily usable via codecs.encode() and codecs.decode()
even without .transform() and .untransform().

Esp. the hex codec is very handy and at least in our eGenix
code base in wide-spread use. Using a single well-defined
interface to such encodings is just much more user friendly
than having to research the different APIs for each of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Fri May 28 16:25:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 May 2010 14:25:47 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1275056747.61.0.917670120366.issue7475@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Fri May 28 17:46:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 May 2010 15:46:53 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1275061613.67.0.444267829081.issue1759169@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the patch. Committed as r81582 and r81583.

Antoine was right: subsequent references to Solaris needed to be removed also.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Fri May 28 17:56:25 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Fri, 28 May 2010 15:56:25 +0000
Subject: [issue1100562] deepcopying listlike and dictlike objects
Message-ID: <1275062185.47.0.606189286266.issue1100562@psf.upfronthosting.co.za>


Changes by Ryan Coyner <rcoyner at gmail.com>:


----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100562>
_______________________________________

From report at bugs.python.org  Fri May 28 17:57:02 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Fri, 28 May 2010 15:57:02 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1275062222.72.0.639139107722.issue8713@psf.upfronthosting.co.za>


Changes by Ryan Coyner <rcoyner at gmail.com>:


----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri May 28 18:09:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 28 May 2010 16:09:29 +0000
Subject: [issue8405] Improve test_os._kill (failing on slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1275062969.23.0.882041685228.issue8405@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to trunk in r81584 and py3k in r81585.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8405>
_______________________________________

From report at bugs.python.org  Fri May 28 18:30:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 16:30:05 +0000
Subject: [issue8405] Improve test_os._kill (failing on slow machines)
In-Reply-To: <1271299322.61.0.635546677584.issue8405@psf.upfronthosting.co.za>
Message-ID: <1275064205.75.0.726810350811.issue8405@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Committed to trunk in r81584 and py3k in r81585

"sparc solaris10 gcc trunk" buildbot slave doesn't compile anymore. I'm not sure that it's related, so I prefer to not reopen the issue :-)

http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/891

-----------
...
building '_struct' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/home2/buildbot/slave/trunk.loewis-sun/build/Include -I/home2/buildbot/slave/trunk.loewis-sun/build -c /home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.c -o build/temp.solaris-2.10-sun4u-2.7-pydebug/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.o
gcc -shared build/temp.solaris-2.10-sun4u-2.7-pydebug/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.o -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.7-pydebug/_struct.so
Assertion failed: min >= 0, file Python/getargs.c, line 1826
*** Error code 134
The following command caused the error:
case $MAKEFLAGS in \
*s*)  CC='gcc' LDSHARED='gcc -shared' LDFLAGS='' OPT='-g -O0 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*)  CC='gcc' LDSHARED='gcc -shared' LDFLAGS='' OPT='-g -O0 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: Fatal error: Command failed for target `sharedmods'
program finished with exit code 1
-----------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8405>
_______________________________________

From report at bugs.python.org  Fri May 28 18:48:12 2010
From: report at bugs.python.org (Mike Hobbs)
Date: Fri, 28 May 2010 16:48:12 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>


New submission from Mike Hobbs <mhobbs at alvenda.com>:

Condition.wait() without a timeout will never raise a KeyboardInterrupt:

cond = threading.Condition()
cond.acquire()
cond.wait()

*** Pressing Ctrl-C now does nothing ***



If you pass a timeout to Condition.wait(), however, it does behave as expected:

cond.wait()

^CTraceback (most recent call last):
  File "/usr/lib/python3.1/threading.py", line 242, in wait
    _sleep(delay)
KeyboardInterrupt



This may affect other problems reported with multiprocessing pools. Most notably:
http://bugs.python.org/issue8296
http://stackoverflow.com/questions/1408356

----------
components: Library (Lib)
messages: 106678
nosy: hobb0001
priority: normal
severity: normal
status: open
title: Condition.wait() doesn't raise KeyboardInterrupt
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Fri May 28 19:29:32 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 28 May 2010 17:29:32 +0000
Subject: [issue4015] [patch] make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1275067772.22.0.19616639395.issue4015@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This issue is so old and I do not have time to reread it fully, unfortunately. I believe I wanted to install packages using "easy_install", "pip" or whatever I have and get Scripts/something.bat for  my version of Python. This version is often portable, so registry dependency it is not an option - not a good version at least. Scripts/ can also be located in virtualenv.

The similar patch is used for deploying SCons on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri May 28 19:40:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 17:40:40 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1275068440.31.0.270590984388.issue8844@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In 3.2, even using a timeout doesn't make the call interruptible.
The solution would be to fix the internal locking APIs so that they handle incoming signals properly, and are able to return an error status.

----------
nosy: +gregory.p.smith, jyasskin, pitrou, rnk
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Fri May 28 19:43:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 May 2010 17:43:10 +0000
Subject: [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1275068590.32.0.305694115287.issue8834@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

LGTM as well.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8834>
_______________________________________

From report at bugs.python.org  Fri May 28 19:49:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 17:49:36 +0000
Subject: [issue8835] buildbot: support.transient_internet() doesn't catch DNS
	socket.gaierror
In-Reply-To: <1274996857.49.0.779391183304.issue8835@psf.upfronthosting.co.za>
Message-ID: <1275068976.44.0.972551551823.issue8835@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I commited the patch as r81571 in trunk.

Apparently it's ok.

----------
assignee:  -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8835>
_______________________________________

From report at bugs.python.org  Fri May 28 19:54:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 May 2010 17:54:09 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I have a use case where I'd like to be able to check whether or not there is an uncommitted transaction.  The use case is a REPL database editor.  If the user issues the 'save' command a commit is done.  When they quit the application, I'd like to be able to prompt them with a 'save or discard' if and only if they have made changes since the last save.  Exposing the connection's inTransaction attribute would allow me to do this.  The attached patch does this as a read only attribute named in_transaction.  I'll add unit tests if this idea isn't rejected.

----------
components: Extension Modules
files: sqlite.in_transaction.patch
keywords: easy, patch
messages: 106683
nosy: ghaering, r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: Expose sqlite3 connection inTransaction as read-only in_transaction attribute
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17482/sqlite.in_transaction.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 19:56:55 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 28 May 2010 17:56:55 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275069415.11.0.692806072955.issue8845@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 21:10:06 2010
From: report at bugs.python.org (David Watson)
Date: Fri, 28 May 2010 19:10:06 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1275073806.38.0.770578164309.issue6560@psf.upfronthosting.co.za>


David Watson <baikie at users.sourceforge.net> added the comment:

Here is a new version of the patch; I've added some tests which
use the RFC 3542 interface (IPv6 advanced API) and am now quite
happy with it generally.

As well as Linux, I've tested it on an old (unsupported) FreeBSD
5.3 installation, which required a few changes in the tests and
the code, but is probably representative of many socket
implementations.  Testing on other systems would be appreciated!

The main issue was that when truncating ancillary data, FreeBSD
seemed to just copy as much into the buffer as would fit and did
not adjust the last item's cmsg_len member to reflect the amount
of data that was actually present, so the item would appear to
extend past the end of the buffer.  The last version of the patch
detected this and raised RuntimeError, which prevented any
truncated receives from succeeding.  The new version instead
issues a warning and returns as much of the last item as is in
the buffer.

The warning could perhaps be disabled for systems like this,
given that it happens every time ancillary data is truncated, but
truncation generally shouldn't happen in a program's normal
operation, and on other platforms a bad cmsg_len value might
indicate that the returned data is actually incorrect in some
way.


After some investigation, I've stuck with using CMSG_FIRSTHDR()
and CMSG_NXTHDR() to step through the headers when assembling the
ancillary data in sendmsg().

The KAME IPv6 userspace utilities at [1] include several programs
which send multiple control messages at once, and these always
use CMSG_NXTHDR() to advance to the next uninitialized header,
while some (but not all) of them zero-fill the buffer beforehand,
suggesting they ran into the issue with glibc's macros returning
NULL (KAME developed the BSD IPv6 stack, and the zero-filling
isn't necessary with the BSD macros).

The alternative would be to add CMSG_SPACE(size) to the pointer
to get to the next header.  Going by the diagram in RFC 3542,
that should be equivalent, but if some system defined
CMSG_SPACE(len) as, say, CMSG_LEN(len) + 3, instead of
(CMSG_LEN(len) + 3) & ~3, it would probably go unnoticed until
someone tried to use CMSG_SPACE() that way.  So given the KAME
example, I think using CMSG_NXTHDR() with a zero-filled buffer is
the way to go.


[1] http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/

----------
Added file: http://bugs.python.org/file17483/baikie-hwundram-v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Fri May 28 21:16:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 19:16:22 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1275074182.4.0.501700733756.issue8844@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

3.2 is interesting in that it introduces a new internal API: PyThread_acquire_lock_timed(). We can therefore change that API again before release without risking any compatibility breakage. Reid, would you want to work on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Fri May 28 21:17:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 May 2010 19:17:28 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1275074248.72.0.969013483101.issue6560@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Fri May 28 21:33:47 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 28 May 2010 19:33:47 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275075227.99.0.115490082491.issue8845@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Tested this patch, works perfectly fine. Also it suits for the particular use case which David mentioned where there is no better alternate approach.

----------
Added file: http://bugs.python.org/file17484/dbapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 21:37:04 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 28 May 2010 19:37:04 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275075424.2.0.0952312815406.issue8845@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

> If the user issues the 'save' command a commit is done.  When they quit the application, I'd like to be able to prompt them with a 'save or discard' if and only if they have made changes since the last save.

Isn't this the same as "if they have issued any non-SELECT" statements?  And isn't that pretty easy to track?

(Not that I'm opposed to making the SQLite3 wrapper more complete.)

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 21:42:42 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 28 May 2010 19:42:42 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275075762.18.0.0404217124091.issue8845@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Removed file: http://bugs.python.org/file17484/dbapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 21:46:49 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 28 May 2010 19:46:49 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275076009.98.0.0209950923038.issue8845@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

>>> conn = sqlite3.connect('dbdump.sqlite')
>>> c = conn.cursor()
>>> conn.in_transaction
False
>>> c.execute('CREATE TABLE foo (id integer, name text)')
<sqlite3.Cursor object at 0x1004a7730>
>>> conn.in_transaction
False

It gives True for Insert and False for Select. perfect Ok. However It should give True when we Create tables ?

Adding unit-test which upon showing this behavior fails the test.

----------
Added file: http://bugs.python.org/file17485/dbapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 22:23:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 May 2010 20:23:47 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275078227.12.0.324137106226.issue8845@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

@exarkun: yes, but since the module is already tracking that information, it seems silly to duplicate it in my code, especially since that duplication could include data-losing bugs.

@l0nwlf: its behaviour is in accord with the module documentation, which talks about the fact that issuing a create statement (for example) commits the current transaction.  So in_transaction is an accurate representation of what sqlite3 is actually doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 22:31:28 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 28 May 2010 20:31:28 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275078688.45.0.463226528609.issue8845@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


Removed file: http://bugs.python.org/file17485/dbapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 22:32:01 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 28 May 2010 20:32:01 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275078721.53.0.0195793192781.issue8845@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Ok then.

Uploading unit-test which takes value of in_transaction as False after issuing a Create statement. It passes with the patch applied.

----------
Added file: http://bugs.python.org/file17486/dbapi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Fri May 28 22:54:40 2010
From: report at bugs.python.org (Andre Wobst)
Date: Fri, 28 May 2010 20:54:40 +0000
Subject: [issue8846] cgi.py bug report + fix: tailing carriage return and
	newline characters in multipart cgi input broken
In-Reply-To: <1275080080.41.0.761400748474.issue8846@psf.upfronthosting.co.za>
Message-ID: <1275080080.41.0.761400748474.issue8846@psf.upfronthosting.co.za>


New submission from Andre Wobst <wobsta at users.sourceforge.net>:

There are serious bugs in carriage return and newline handling at the end of a multipart cgi input. The enclosed patch extends the test_cgi.py (and actually reverts two wrong tests to what they had been for python2.x). Additionally, the bugs are fixed by two small corrections to cgi.py and email/feedparser.py. Thanks for consideration.

----------
components: Library (Lib)
files: fix-cgi.patch
keywords: patch
messages: 106691
nosy: wobsta
priority: normal
severity: normal
status: open
title: cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken
versions: Python 3.3
Added file: http://bugs.python.org/file17487/fix-cgi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8846>
_______________________________________

From report at bugs.python.org  Fri May 28 22:56:35 2010
From: report at bugs.python.org (Andre Wobst)
Date: Fri, 28 May 2010 20:56:35 +0000
Subject: [issue8846] cgi.py bug report + fix: tailing carriage return and
	newline characters in multipart cgi input broken
In-Reply-To: <1275080080.41.0.761400748474.issue8846@psf.upfronthosting.co.za>
Message-ID: <1275080195.3.0.543466060113.issue8846@psf.upfronthosting.co.za>


Changes by Andre Wobst <wobsta at users.sourceforge.net>:


----------
type:  -> behavior
versions: +Python 3.1 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8846>
_______________________________________

From report at bugs.python.org  Fri May 28 23:55:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 May 2010 21:55:59 +0000
Subject: [issue8837] PyArg_ParseTuple(): remove old and unused "O?" format
In-Reply-To: <1275001181.3.0.513228371252.issue8837@psf.upfronthosting.co.za>
Message-ID: <1275083759.75.0.058426303103.issue8837@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r81588 (py3k), blocked in 3.1 (r81589).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8837>
_______________________________________

From report at bugs.python.org  Sat May 29 00:29:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 May 2010 22:29:28 +0000
Subject: [issue8838] Remove codecs.readbuffer_encode()
	and	codecs.charbuffer_encode()
In-Reply-To: <4BFFC123.2070702@netwok.org>
Message-ID: <4C0043C5.2090205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin said these codecs are coming back in 3.2.

I think you are confusing me with MAL. I remain opposed to adding them 
back. Users ought to use the modules that provide these these 
conversions as functions.

----------
title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and	codecs.charbuffer_encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8838>
_______________________________________

From report at bugs.python.org  Sat May 29 00:37:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 May 2010 22:37:02 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275086222.07.0.0245849671324.issue8845@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch lacks documentation. Otherwise, I think it's fine.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sat May 29 00:53:47 2010
From: report at bugs.python.org (benrg)
Date: Fri, 28 May 2010 22:53:47 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>


New submission from benrg <benrudiak at gmail.com>:

c:\>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.
  >>> from collections import namedtuple
  >>> foo = namedtuple('foo', '')
  >>> [1] + foo()

At this point the interpreter crashes. Also happens when foo has named arguments, and in batch scripts. foo() + [1] throws a TypeError as expected. [] + foo() returns (). The immediate cause of the crash is the CALL instruction at 1E031D5A in python31.dll jumping into uninitialized memory.

----------
components: Interpreter Core, Library (Lib), Windows
messages: 106695
nosy: benrg
priority: normal
severity: normal
status: open
title: crash appending list and namedtuple
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Sat May 29 01:03:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 May 2010 23:03:26 +0000
Subject: [issue8840] io.StringIO: truncate+print disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275087806.75.0.067819175129.issue8840@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This should not have been closed yet.

The announced policy is that bugfix releases should not add or change APIs. I think this hidden change (there is no What' New in 3.1.2 doc) should be reverted in 3.1.3. I will post on py-dev for other opinions.

That aside, I think both the current behavior and docs are buggy and should be changed for 3.2 (and 3.1.3 if not reverted).

1. If the file pointer is not moved, then it seems to me that line 3 of my example output should have been '\0\0\0\0' instead of ''. The current behavior is '' + 'abc\n' == '\0\0\0\0abc\n', which is not sane. Maybe .getvalue() needs to be changed. It is hard to further critique the observed behavior since the intent is, to me, essentially undocumented.

2. The current 3.1.2/3.2a0 manual entry

"truncate(size=None)
    Truncate the file to at most size bytes. size defaults to the current file position, as returned by tell(). Note that the current file position isn?t changed; if you want to change it to the new end of file, you have to seek() explicitly."

 has several problems.

a. 'file' should be changed to 'stream' to be consistent with other entries.

b. If "truncate the file to at most size bytes" does not mean 'change the steam position', then I have no idea what it is supposed to mean, or what .truncate is actually supposed to do.

c. There is no mention that what is does do is to replace existing chars with null chars. (And the effect of that is/should be different in Python than in C.)

d. There is no mention of the return value and what *it* is supposed to mean.

3. The current 3.1.2 (and I presume, 3.2a0) doc string (help entry)

"truncate(...)
    Truncate size to pos.
    
    The pos argument defaults to the current file position, as
    returned by tell().  The current file position is unchanged.
    Returns the new absolute position."

also has problems.

a. Same change of 'file' to 'stream'.

b. I already commented on ... and 'truncate size to pos', but to be consistent with the manual, the arg should be called 'size' rather that 'pos', or vice verse.

c. 'truncate' does not define the meaning of 'truncate', especially when it no longer means what a native English speaker would expect it to mean.

d. To me, 'the *new* absolute position' contradicts 'The current file position is *unchanged*' [emphases added]. Is there some subtle, undocumented, distinction between 'absolute position' and 'file [stream] position'?

In any case, .truncate(0) returns 0, which seems to become the new position for .getvalue() but not for appending chars with print. To me, having *two* steams positions for different functions is definitely a bug.

4. There is no mention of a change to .truncate in What's New in Python 3.2.

After searching more, I see that the change was discussed in #6939, by only two people. I see no justification there for changing 3.1 instead of waiting for 3.2. The OP suggested in his initial message, as I do here, that the doc say something about what .truncate does do with respect to padding, but that did not happen.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 01:30:55 2010
From: report at bugs.python.org (Chris Leary)
Date: Fri, 28 May 2010 23:30:55 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1275089455.9.0.344668735993.issue7593@psf.upfronthosting.co.za>


Changes by Chris Leary <christopher.leary at cornell.edu>:


----------
nosy: +cdleary

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Sat May 29 02:07:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 00:07:20 +0000
Subject: [issue8215] getargs.c in Python3 contains some TODO and the
	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1275091640.36.0.763704176734.issue8215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to cleanup getbuffer() and convertbuffer():
 - getbuffer() doesn't call convertbuffer() if pb->bf_getbuffer==NULL. If pb->bf_getbuffer==NULL, PyObject_GetBuffer() fails and so the call to convertbuffer() is useless.
 - convertbuffer() calls getbuffer() to check that the buffer is 'C" contiguous (and to factorize the code)
 - release the buffer if the buffer is not contigous => fix a bug
 - rename "errmsg" and "buf" to "expected" to reuse converterror() term
 - Remove /* XXX Really? */: I don't understand the comment and the code looks ok

The main change is that convertbuffer() now requires a "C" contiguous buffer. That change concerns "s#", "y", "z" and "t#" formats.

If a function would like to support non contiguous buffers, it should use "O" format and then PyObject_GetBuffer(). I don't think that builtin Python functions do support non contiguous buffers.

----------
keywords: +patch
Added file: http://bugs.python.org/file17488/getarg_cleanup_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8215>
_______________________________________

From report at bugs.python.org  Sat May 29 03:38:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 01:38:48 +0000
Subject: [issue8848] Remove "U" and "U#" formats of Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"U" and "U#" formats were introduced by r55433 (Python3). At this same, "s" and "U" formats were different: "s" called PyString_FromStringAndSize() and "U" called PyUnicode_FromStringAndSize(). Two months later, PyString_FromStringAndSize() was replaced by PyUnicode_FromStringAndSize() for format "s", and so both formats are exactly the same.

"U" and "U#" were introduced during the transition between bytes, str and unicode. They can now be replaced by "s" and "s#", and then be removed.

There is just one usage of "U": definition of sys.subversion (Python/sysmodule.c), whereas there are 36 usages of "s" format. (U# and s# are not used.)

----------
components: Interpreter Core
messages: 106700
nosy: doerwalter, haypo
priority: normal
severity: normal
status: open
title: Remove "U" and "U#" formats of Py_BuildValue()
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8848>
_______________________________________

From report at bugs.python.org  Sat May 29 04:23:09 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 29 May 2010 02:23:09 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1275099789.26.0.566216381001.issue2516@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Sat May 29 04:24:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 02:24:20 +0000
Subject: [issue8850] Remove "w" format of PyParse_ParseTuple()
In-Reply-To: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>
Message-ID: <1275099860.74.0.46695580149.issue8850@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"w" format is dangerous because it doesn't give the size of the buffer: the caller may write outside the buffer (buffer overflow).

"w*" and "w#" formats are fine.

It looks like "w" format is not used in trunk nor py3k (only w# and w*).

----------
components: Interpreter Core
messages: 106702
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove "w" format of PyParse_ParseTuple()
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8850>
_______________________________________

From report at bugs.python.org  Sat May 29 04:34:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 02:34:39 +0000
Subject: [issue8215] getargs.c in Python3 contains some TODO and the
	documentation is outdated
In-Reply-To: <1269383341.97.0.71915040037.issue8215@psf.upfronthosting.co.za>
Message-ID: <1275100479.27.0.416759734649.issue8215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to update the documenation, especially input types for PyArg_ParseTuple() and output types for Py_BuildValue():

 - add bytes and/or bytearray when buffer compatible object is accepted to be more explicit
 - "es", "et", "es#", "et#" don't accept buffer compatible objects: fix the doc
 - specify utf-8 encoding
 - mark "U" and "U#" as deprecated: see issue #8848
 - fix ".. note::" syntax
 - replace "Unicode" by "str"
 - replace "bytes object" by "bytes"
 - replace "any buffer compatible object" by "buffer compatible object"

I hesitate to add explicit quotes, eg. "s" instead of s.

----------
Added file: http://bugs.python.org/file17490/doc_capi_arg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8215>
_______________________________________

From report at bugs.python.org  Sat May 29 04:39:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 02:39:33 +0000
Subject: [issue8848] Remove "U" and "U#" formats of Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275100773.3.0.540404434827.issue8848@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Less extreme patch: set 'U' as an alias to 's' (and 'U#' as an alias to 's#'). Replace usage of 'U' by 's'.

Note: 'z' is also an alias to 's', and 'z#' an alias to 's#'.

----------
keywords: +patch
Added file: http://bugs.python.org/file17491/py_buildvalue_removeU.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8848>
_______________________________________

From report at bugs.python.org  Sat May 29 04:39:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 May 2010 02:39:47 +0000
Subject: [issue8848] Deprecate or remove "U" and "U#" formats of
	Py_BuildValue()
In-Reply-To: <1275097128.66.0.216673219733.issue8848@psf.upfronthosting.co.za>
Message-ID: <1275100787.37.0.483167298587.issue8848@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Remove "U" and "U#" formats of Py_BuildValue() -> Deprecate or remove "U" and "U#" formats of Py_BuildValue()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8848>
_______________________________________

From report at bugs.python.org  Sat May 29 04:59:29 2010
From: report at bugs.python.org (Reid Kleckner)
Date: Sat, 29 May 2010 02:59:29 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1275101969.79.0.264603516238.issue8844@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

I'd like to fix it, but I don't know if I'll be able to in time.  It was something that bugged me while running the threading tests while working on Unladen.

I'm imagining (for POSIX platforms) adding some kind of check for signals when the system call returns EINTR.  If the signal handler raises an exception, like an interrupt should raise a KeyboardInterrupt, we can just give a different return code and propagate the exception.

It also seems like this behavior can be extended gradually to different platforms, since I don't have the resources to change and test every threading implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Sat May 29 05:43:40 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 May 2010 03:43:40 +0000
Subject: [issue8840] io.StringIO: truncate+print disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275104620.22.0.727509407303.issue8840@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the record, Guido's decision to change 3.1: http://mail.python.org/pipermail/python-dev/2009-September/092247.html

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 05:46:17 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 29 May 2010 03:46:17 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1275104777.7.0.152740130798.issue6939@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To avoid any confusion in the future, it should be noted that Antoine did not unilaterally make the decision to commit this change to a maintenance branch.

This change was discussed on python-dev, with the ultimate decision to update the 3.1 semantics being made by Guido: http://mail.python.org/pipermail/python-dev/2009-September/092247.html

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sat May 29 06:38:21 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Sat, 29 May 2010 04:38:21 +0000
Subject: [issue8851] pkgutil document needs more markups
In-Reply-To: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>
Message-ID: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

The library reference of pkgutil is only sparsely marked up.

The attached patch is against 2.6 version, because I'm currently working with 2.6.  Since a part of markups (namely :pep:'s) has already been done for 3.2 version, the patch cannot be applied directly to that version, and I haven't checked the versions in between.

----------
assignee: docs at python
components: Documentation
files: pkgutil.diff
keywords: patch
messages: 106708
nosy: docs at python, mft
priority: normal
severity: normal
status: open
title: pkgutil document needs more markups
versions: Python 2.6
Added file: http://bugs.python.org/file17492/pkgutil.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8851>
_______________________________________

From report at bugs.python.org  Sat May 29 07:18:06 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 29 May 2010 05:18:06 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1275110286.75.0.546161128738.issue1724822@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Sat May 29 08:39:51 2010
From: report at bugs.python.org (Wichert Akkerman)
Date: Sat, 29 May 2010 06:39:51 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1275115191.27.0.598640062046.issue2504@psf.upfronthosting.co.za>


Wichert Akkerman <wichert at wiggy.net> added the comment:

Martin, is there anything we can do to help get this merged? I can really use this as well.

My background here is that currently the complete zope i18n support abuses message ids as a workaround, and the result works but is very painful for translators since the original string is not immediately visible for them.

----------
nosy: +wichert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sat May 29 08:48:50 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sat, 29 May 2010 06:48:50 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1275115730.38.0.249484253669.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

I've ported pyliblzma to py3k now and also implemented the missing functionality I mentioned earlier, for anyone interested in my progress the branch is found at:
https://code.launchpad.net/~proyvind/pyliblzma/py3k

I need to fix some memory leakages (side effect of the new PyUnicode/Pybytes change I'm not 100% with yet;) and some various memory errors reported by valgrind etc. though, but things are starting to look quite nice already. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sat May 29 09:36:51 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 29 May 2010 07:36:51 +0000
Subject: [issue8840] io.StringIO: truncate+print disabled in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275118611.93.0.418956973286.issue8840@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

The change was announced in http://docs.python.org/dev/whatsnew/2.7.html, but indeed it wasn't advertised in py3k changes - my apologies, I didn't check it was.

I agree that the doc should be clarified on several aspects.

* The returned value is the new file SIZE indeed (I guess we can still use "file" here, since imo other streams can't be truncated anyway).

* Truncate() simply changes the current end-of-file (the word is historical, resize() would have been better - as this has been discussed on mailing lists).

* Extending the file size with truncate() or with a write() after end-of-file (that's your sample's case) does, or does not (depending on the platform), fill the empty space with zeroes.


Proposal for doc update :

Resizes the file to the given size (or the current position), without moving the file pointer. This resizing can extend or reduce the current file size. In case of extension, the content of the new file area depends on the platform (on most systems, additional bytes are zero-filled, on win32 they're undetermined). Returns the new file size.

Would it be ok thus ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 10:46:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 May 2010 08:46:38 +0000
Subject: [issue8616] Changes to content of Demo/turtle
In-Reply-To: <1273008730.8.0.105084103886.issue8616@psf.upfronthosting.co.za>
Message-ID: <1275122798.58.0.43118694012.issue8616@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I tried again and it worked flawlessly.  Maybe I overlooked a stick last time :)

Committed in r81593.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8616>
_______________________________________

From report at bugs.python.org  Sat May 29 10:49:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 May 2010 08:49:20 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1275122960.46.0.190959525977.issue8811@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, if I try applying your patch to 3.1 it fails.  It would be nice to have one that applies flawlessly :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Sat May 29 11:57:36 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 29 May 2010 09:57:36 +0000
Subject: [issue8792] xmlrpclib compatibility issues with Apache XML-RPC library
In-Reply-To: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>
Message-ID: <1275127056.78.0.320297007692.issue8792@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

A few notes:
1. these types are *not* part of the XML-RPC specification, they are Apache extensions
2. these types seem designed to accommodate Java
3. some of these types would be very possible to accommodate e.g. ex:serializable which contains a serialized Java object

----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8792>
_______________________________________

From report at bugs.python.org  Sat May 29 04:17:53 2010
From: report at bugs.python.org (jroach)
Date: Sat, 29 May 2010 02:17:53 +0000
Subject: [issue8849] python.exe problem with cvxopt
In-Reply-To: <4C007915.6020901@internode.on.net>
Message-ID: <4C007915.6020901@internode.on.net>


New submission from jroach <jroach at internode.on.net>:

I have encountered a runtime problem with python26 (same problem not 
encountered with python25). The reported error is in python.exe.
I have written a brief .doc file describing the problem which I will 
attach. ( The problem was first encountered with an older version of 
python26, it also occurs with the latest  version  2.6.5). The Python 
cvxopt package is available on the internet.
This is my first communication of this type. I hope that it is appropriate.
jroach

----------
files: python26problem.doc
messages: 106701
nosy: jroach
priority: normal
severity: normal
status: open
title: python.exe problem with cvxopt
Added file: http://bugs.python.org/file17489/python26problem.doc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8849>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python26problem.doc
Type: application/msword
Size: 1137664 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100529/ba8b005d/attachment-0001.doc>

From report at bugs.python.org  Sat May 29 12:38:45 2010
From: report at bugs.python.org (Filippo Giunchedi)
Date: Sat, 29 May 2010 10:38:45 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1275129525.37.0.192507415714.issue5673@psf.upfronthosting.co.za>


Changes by Filippo Giunchedi <fgiunchedi at gmail.com>:


----------
nosy: +filippo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Sat May 29 13:44:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 11:44:44 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275101969.79.0.264603516238.issue8844@psf.upfronthosting.co.za>
Message-ID: <1275133478.3124.48.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm imagining (for POSIX platforms) adding some kind of check for
> signals when the system call returns EINTR.  If the signal handler
> raises an exception, like an interrupt should raise a
> KeyboardInterrupt, we can just give a different return code and
> propagate the exception.

Yes, this is what I'm proposing too.

> It also seems like this behavior can be extended gradually to
> different platforms, since I don't have the resources to change and
> test every threading implementation.

There is only one active POSIX threading implementation in 3.2, in
Python/thread_pthread.h.
(and the only non-POSIX one is for Windows)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Sat May 29 13:47:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 11:47:01 +0000
Subject: [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275133621.55.0.16307573684.issue8840@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: io.StringIO: truncate+print disabled in 3.1.2 -> truncate() semantics changed in 3.1.2
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 13:56:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 11:56:20 +0000
Subject: [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275134180.24.0.505928753974.issue8840@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How about reusing the documentation of legacy file objects:

?Truncate the file?s size. If the optional size argument is present, the file is truncated to (at most) that size. The size defaults to the current position. The current file position is not changed. Note that if a specified size exceeds the file?s current size, the result is platform-dependent: possibilities include that the file may remain unchanged, increase to the specified size as if zero-filled, or increase to the specified size with undefined new content.?

http://docs.python.org/library/stdtypes.html#file.truncate

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 14:09:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 12:09:23 +0000
Subject: [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275134963.21.0.924770990676.issue8840@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a doc update (a mix of the legacy truncate() doc and Pascal's proposal) in r81594.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 15:48:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 May 2010 13:48:04 +0000
Subject: [issue8849] python.exe problem with cvxopt
In-Reply-To: <4C007915.6020901@internode.on.net>
Message-ID: <1275140884.5.0.432808728378.issue8849@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Rather than attaching a Word document, can you just enter your information here?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8849>
_______________________________________

From report at bugs.python.org  Sat May 29 16:30:13 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 29 May 2010 14:30:13 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>


New submission from David Kirkby <david.kirkby at onetel.net>:

Using Python 2.6.5, the module _socket is failing to build on OpenSolaris. The problem can be worked around with a hack, but I've not verified if the hack actually results in working code - but at least it compiles. See below. 

The problem seems to be that HAVE_NETPACKET_PACKET_H gets defined, despite the fact there is no file called netpacket.h

running build
running build_ext
building '_socket' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?makesockaddr?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1107: error: ?struct ifreq? has no member named ?ifr_ifindex?
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: ?SIOCGIFNAME? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: (Each undeclared identifier is reported only once
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: for each function it appears in.)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?getsockaddrarg?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1415: error: ?SIOCGIFINDEX? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1427: error: ?struct ifreq? has no member named ?ifr_ifindex?
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?init_socket?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4596: error: ?PACKET_LOOPBACK? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: ?PACKET_FASTROUTE? undeclared (first use in this function)
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c: In function ?PyCursesWindow_ChgAt?:
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c:708: warning: implicit declaration of function ?mvwchgat?
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c:712: warning: implicit declaration of function ?wchgat?
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.solaris-2.11-i86pc-2.6/_curses.so
*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc-2.6/_curses.so: symbol mvwchgat: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.o
gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.o -L/usr/local/lib -lpanel -lcurses -ltermcap -o build/lib.solaris-2.11-i86pc-2.6/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses
building 'sunaudiodev' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I.

A patch (which is a hack, rather than a real solution), is below. 

drkirkby at hawk:~/Python-2.6.5/Modules$ diff -U 10  socketmodule.c.orig socketmodule.c
--- socketmodule.c.orig	Sat May 29 14:58:17 2010
+++ socketmodule.c	Sat May 29 15:26:08 2010
@@ -1089,20 +1089,21 @@
 		}
 #endif
 
 		default:
 			PyErr_SetString(PyExc_ValueError,
 					"Unknown Bluetooth protocol");
 			return NULL;
 		}
 #endif
 
+#undef HAVE_NETPACKET_PACKET_H /* Hack to build on OpenSolaris x64 */
 #ifdef HAVE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		struct sockaddr_ll *a = (struct sockaddr_ll *)addr;
 		char *ifname = "";
 		struct ifreq ifr;
 		/* need to look up interface name give index */
 		if (a->sll_ifindex) {
 			ifr.ifr_ifindex = a->sll_ifindex;
 			if (ioctl(sockfd, SIOCGIFNAME, &ifr) == 0)

----------
messages: 106719
nosy: drkirkby
priority: normal
severity: normal
status: open
title: _socket fails to build on OpenSolaris x64
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 16:32:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 May 2010 14:32:38 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1275143558.94.0.997153066636.issue8847@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can't reproduce this on either 3.1.2 or py3k trunk.

----------
nosy: +r.david.murray
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Sat May 29 16:46:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 29 May 2010 14:46:14 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275144374.5.0.292927293152.issue8852@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please verify that HAVE_NETPACKET_PACKET_H does indeed get defined, looking at pyconfig.h.

Please inspect config.log to find out why it does get defined.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 17:15:01 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 29 May 2010 15:15:01 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275146101.37.0.19211914251.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> I'm not sure that's a good idea:  mightn't this change behaviour for 
> user-defined classes with a __coerce__ method?  Maybe it would be 
> better to just special-case ints and longs at the start of 
> complex_richcompare, and then leave everything else more-or-less 
> intact?

I looked into this more and agree.  I have attached a patch with the strategy that leaves the coercion intact.  Although, even with removing the coercion from the complex rich compare a user-defined __coerce__ is still called somewhere up in object.c.  It does not have the same behavior, though, e.g. __coerce__ is called, but the coerced args don't actually seem to be used in the comparison as they are in the explicit coerce in the complex object rich compare.

Somewhat of topic, but the comparison rules in 2.7 seems to be pretty inconsistent anyway (due to different behavior between new and old style classes):

motherbrain:trunk minge$ ./python.exe 
Python 2.7b2+ (trunk:81489M, May 29 2010, 09:44:06) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from itertools import product
[35627 refs]
>>> class T:
...    def __init__(self, x):
...       self.x = x
...    def __coerce__(self, other):
...       return (self.x, other)
... 
[35676 refs]
>>> class U(T, object):
...    def __init__(self, x):
...       super(U, self).__init__(x)
... 
[35723 refs]
>>> for tobj, value in product((T, U), (12, 12.0, complex(12.0))):
...    print tobj, " -> ", tobj(value) == value
... 
__main__.T  ->  True
__main__.T  ->  True
__main__.T  ->  True
<class '__main__.U'>  ->  True
<class '__main__.U'>  ->  False
<class '__main__.U'>  ->  True
[35740 refs]
>>> 


Given the complexities and subtleties of how comparison works in 2.7 I am a little hesitant to commit this change as well.

----------
Added file: http://bugs.python.org/file17493/issue-8748.py27.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sat May 29 17:24:02 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 29 May 2010 15:24:02 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275146642.71.0.92806737525.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I was obviously looking for the wrong file. ./pyconfig.h shows:

/* Define to 1 if you have the <netpacket/packet.h> header file. */
#define HAVE_NETPACKET_PACKET_H 1

the file does indeed exist

drkirkby at hawk:~$ find /usr/include -name packet.h
/usr/include/netpacket/packet.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 17:24:15 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 29 May 2010 15:24:15 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275146655.79.0.0847641157875.issue8748@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sat May 29 17:26:34 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 29 May 2010 15:26:34 +0000
Subject: [issue2470] Need fixer for dl (removed) -> ctypes module
In-Reply-To: <1206339875.66.0.189262293555.issue2470@psf.upfronthosting.co.za>
Message-ID: <1275146794.07.0.239898709869.issue2470@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2470>
_______________________________________

From report at bugs.python.org  Sat May 29 17:33:24 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 29 May 2010 15:33:24 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275147204.25.0.505225725564.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Two points I should have stated. 

1) http://www.lotuseyes.de/blog/error-installing-plone-on-opensolaris-using-the-unified-installer

has a discussion about this issue. It was related to someone trying to install "Plone" but the problem is a failure of _socket to build. I'm trying to build the port the Sage maths software to OpenSolaris, and hit the problem there. 

2) If a *serious* developer would like access to the OpenSolaris machine which shows this problem, I can give you a temporary account. Drop me a private email. Otherwise, you can install OpenSolaris on a virtual machine under VirtualBox, or I can do my best to debug it with some help from a developer. 


Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 17:51:54 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Sat, 29 May 2010 15:51:54 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1275148314.31.0.160713981787.issue8651@psf.upfronthosting.co.za>


Changes by Ryan Coyner <rcoyner at gmail.com>:


----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Sat May 29 17:52:09 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Sat, 29 May 2010 15:52:09 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1275148329.62.0.549987922007.issue8650@psf.upfronthosting.co.za>


Changes by Ryan Coyner <rcoyner at gmail.com>:


----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Sat May 29 18:47:16 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 29 May 2010 16:47:16 +0000
Subject: [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275151636.48.0.965093881733.issue8840@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Good B-)

Woudl it be necessary to update the docstrings too ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8840>
_______________________________________

From report at bugs.python.org  Sat May 29 19:48:13 2010
From: report at bugs.python.org (AndiDog)
Date: Sat, 29 May 2010 17:48:13 +0000
Subject: [issue8853] getaddrinfo should accept port of type long
In-Reply-To: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>
Message-ID: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>


New submission from AndiDog <AndiDog at web.de>:

socket.getaddrinfo("127.0.0.1", 80L)
error: Int or String expected

I would expect getaddrinfo to convert the port number to an integer.

----------
components: Library (Lib)
messages: 106726
nosy: AndiDog
priority: normal
severity: normal
status: open
title: getaddrinfo should accept port of type long
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8853>
_______________________________________

From report at bugs.python.org  Sat May 29 20:30:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 29 May 2010 18:30:55 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275157855.98.0.057471394799.issue8852@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The AF_PACKET support was original meant for Linux. When Solaris now also supports that socket family, and with a similar interface, it might be interesting to port that support to Solaris.

If nobody volunteers, it might be easier to restrict this to Linux only; please try the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file17494/afpacket.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 20:56:55 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 18:56:55 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275159415.88.0.346745518392.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

In this case, the docs.python.org link you point to seems to be correct, saying that it returns a timedelta.  It is the docstring that says it's minutes east of UTC.

I've attached a patch which changes this wording to:

timedelta() showing offset from UTC, with negative for West of UTC

----------
keywords: +patch
nosy: +jafo
Added file: http://bugs.python.org/file17495/python-utcoffsetdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Sat May 29 21:09:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 19:09:37 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275160177.47.0.73477997632.issue8810@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure about the ?with negative? wording.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Sat May 29 21:36:28 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 19:36:28 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275161788.82.0.0379341156545.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Alternately, here is a patch that just takes the docs.python.org description.

----------
Added file: http://bugs.python.org/file17496/python-utcoffsetdoc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Sat May 29 21:37:56 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 19:37:56 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275161876.01.0.883720329765.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Then how about:

timedelta() showing offset from UTC, negative values indicating West of UTC

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Sat May 29 21:43:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 19:43:35 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1275161876.01.0.883720329765.issue8810@psf.upfronthosting.co.za>
Message-ID: <4C016E64.2080301@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> timedelta() showing offset from UTC, negative values indicating West of UTC

+1 for the last one.

Micro nit: I would not put parentheses when referring to the type (we
talk about ?a list?, not ?a list()?).

Micro nit: Some languages use case to distinguish direction vs. region,
e.g. in French we have ?ouest? and ?Ouest?. Does that apply to English?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Sat May 29 21:48:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 May 2010 19:48:38 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1275162518.88.0.797342796301.issue1289118@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The patch looks good to me.  Please replace the tab characters in datetimemodule.c with spaces, though. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Sat May 29 22:00:02 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 20:00:02 +0000
Subject: [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1275163202.32.0.769928574948.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I'm fine without ().

I thought the direction was generally initial-capped, but I may be wrong there.  Let's go with "west".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8810>
_______________________________________

From report at bugs.python.org  Sat May 29 22:22:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:22:44 +0000
Subject: [issue8470] Let cmd.cmd.intro be unicode friendly
In-Reply-To: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>
Message-ID: <1275164564.36.0.177256103462.issue8470@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Since 2.7 is nearing the second beta, I?m afraid no new features can be added.

Note that classes using cmd in 3.x get Unicode arguments.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8470>
_______________________________________

From report at bugs.python.org  Sat May 29 22:26:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:26:47 +0000
Subject: [issue8470] Let cmd.cmd.intro be unicode friendly
In-Reply-To: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>
Message-ID: <1275164807.03.0.844856031172.issue8470@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Correction: beta is behind us, it?s nearly rc time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8470>
_______________________________________

From report at bugs.python.org  Sat May 29 22:38:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:38:28 +0000
Subject: [issue8473] doctest fails if you have inconsistent lineendings
In-Reply-To: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>
Message-ID: <1275165508.64.0.214755979344.issue8473@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me. Is there?s no disagreement on this being a bug fix rather than a new feature, it could go before the rc.

----------
components: +Library (Lib) -Extension Modules, Tests
nosy: +merwok
priority: normal -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8473>
_______________________________________

From report at bugs.python.org  Sat May 29 22:38:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:38:54 +0000
Subject: [issue8473] doctest fails if you have inconsistent lineendings
In-Reply-To: <1271781617.9.0.374951389596.issue8473@psf.upfronthosting.co.za>
Message-ID: <1275165534.17.0.00304809144113.issue8473@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8473>
_______________________________________

From report at bugs.python.org  Sat May 29 22:41:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 May 2010 20:41:25 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275165685.1.0.955827100786.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Given the complexities and subtleties of how comparison works in 2.7
> I am a little hesitant to commit this change as well.

Understood.  Given how long we've lived with this behaviour in 2.x with no serious ill effects, it's very tempting to call this a "won't fix" for 2.7.  Really the coercion for complex types should have been removed at some point in the 2.x series, but it's too late for that now.

I'll take a look at the patch, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sat May 29 22:49:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:49:38 +0000
Subject: [issue8481] doc: ctypes no need to explicitly allocate writable
	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1275166178.94.0.826275388942.issue8481@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: theller -> flox
nosy: +docs at python, flox -theller
priority: normal -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8481>
_______________________________________

From report at bugs.python.org  Sat May 29 22:51:04 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 29 May 2010 20:51:04 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275166264.31.0.917669489364.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

Hi,

thank you for the patch. 

I hope you can keep Python building the same modules on Solaris as Linux, as that would be a real shame if it did not. This module is used in the Sage maths software. 

I had some difficulty applying your patch using the 'patch' command. 'patch' just kept rejecting the file. Finally I gave up and patched it manually. 

It did not completely solve the problem as PACKET_FASTROUTE and PACKET_LOOPBACK were undeclared too

building '_socket' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/incl
ude -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c -o build/temp.solaris-2.11-i
86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ?init_socket?:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: ?PACKET_LOOPBACK? undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: (Each undeclared identifier is reported only once
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: for each function it appears in.)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4598: error: ?PACKET_FASTROUTE? undeclared (first use in this function)
building '_ssl' extension

However, I decided to alter the Modules/socketmodule.c further and finally _socket built. I don't however know how to test _socket, so I don't know if it working or not. (I'm not a python programmer - just about to start learning it). But using

drkirkby at hawk:~/Python-2.6.5$ ./python
Python 2.6.5 (r265:79063, May 29 2010, 21:17:44) 
[GCC 4.4.4] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import _socket
>>> 

it would appear its not completely broken. 

BTW, for the record, the hardware is a Sun Ultra 27 (quad core Xeon) running OpenSolaris 06/2009 which has been updated to build 134. 

drkirkby at hawk:~$ cat /etc/release
                       OpenSolaris Development snv_134 X86
           Copyright 2010 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 01 March 2010

I've built Sage on Solaris 10 (on SPARC hardware), so I don't think this patch is needed on Solaris 10, though I've not checked on Solaris 10 using Intel/AMD hardware. 

Dave

----------
Added file: http://bugs.python.org/file17497/socketmodule.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 22:51:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:51:09 +0000
Subject: [issue8481] doc: ctypes no need to explicitly allocate writable
	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1275166269.46.0.0447462957612.issue8481@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: flox -> theller
nosy: +theller -flox
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8481>
_______________________________________

From report at bugs.python.org  Sat May 29 22:56:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:56:52 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1275166612.03.0.0303842548325.issue8469@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Documentation -Library (Lib)
priority: normal -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Sat May 29 22:58:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 May 2010 20:58:16 +0000
Subject: [issue8469] struct - please make sizes explicit
In-Reply-To: <1271766650.13.0.432849451622.issue8469@psf.upfronthosting.co.za>
Message-ID: <1275166696.0.0.518264763679.issue8469@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8469>
_______________________________________

From report at bugs.python.org  Sat May 29 23:03:48 2010
From: report at bugs.python.org (David Kirkby)
Date: Sat, 29 May 2010 21:03:48 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275167028.08.0.260129917101.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I forget to say I had attached the patch 'socketmodule.c.patch' which allows _socket to build. (I know you can see that if you look, but I thought it useful to write it). 

I do have some other modules not building on OpenSolaris (_curses, _curses_panel, _tkinter & sunaudiodev) but I'll create separate tickets for those. All of those 4 modules are included in the Python 2.6.4 shipped as part of OpenSolaris, so they can be built. 

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sat May 29 23:16:25 2010
From: report at bugs.python.org (Zack Goldstein)
Date: Sat, 29 May 2010 21:16:25 +0000
Subject: [issue7962] Demo/ directory needs to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1275167785.67.0.257921113533.issue7962@psf.upfronthosting.co.za>


Zack Goldstein <goldsz at gmail.com> added the comment:

I've started going through the demos. So far I've gone through cgi and classes. If this is what you're looking for I'll try and go through the rest in the next week or so.

Python 3.2a0

/cgi
    all work

/classes
    Complex.py - fail

            1 and Complex(0, 10) -> <class 'TypeError'>
        Traceback (most recent call last):
          File "Complex.py", line 314, in <module>
            test()
          File "Complex.py", line 310, in test
            checkop(*(t+item))
          File "Complex.py", line 235, in checkop
            ok = abs(result - value) <= fuzz
          File "Complex.py", line 184, in __rsub__
            return other - self
          File "Complex.py", line 180, in __sub__
            return Complex(self.re - other.re, self.im - other.im)
        TypeError: unsupported operand type(s) for -: 'type' and 'int'

    Dates.py - fail
     
        Traceback (most recent call last):
          File "Dates.py", line 227, in <module>
            test(1850, 2150)
          File "Dates.py", line 185, in test
            if (not a < b) or a == b or a > b or b != b:
        TypeError: unorderable types: Date() < Date()

    Dbm.py - fail 
        {}
        key: "myKey"
        Traceback (most recent call last):
          File "Dbm.py", line 66, in <module>
            test()
          File "Dbm.py", line 49, in test
            if key in d:
          File "Dbm.py", line 25, in __getitem__
            return eval(self.db[repr(key)])
        KeyError: '0'

    Range.py - fail
        Exception: error in implementation:
        correct   = range(5, 100, 3)
        old-style = [5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, 47, 50, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98]
        generator = [5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, 47, 50, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98]

    Rev.py - fail
        1 items had failures:
          10 of  17 in Rev
        ***Test Failed*** 10 failures.

        Looks like mostly invalid print syntax
    
    Vec.py - pass

    bitvec.py - fail
        use of __cmp__()
        use of __*slice__()
        didn't check further

----------
nosy: +goldsz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Sat May 29 23:24:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 21:24:03 +0000
Subject: [issue7962] Demo/ directory needs to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1275168243.64.0.306604720746.issue7962@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does ?tested? in the title of this issue mean ?run? or ?unit-tested??

Regarding the 2.7 branch, is this still relevant?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Sat May 29 23:34:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 21:34:14 +0000
Subject: [issue8501] --dry-run option doesn't work
In-Reply-To: <1271972145.51.0.00309332974734.issue8501@psf.upfronthosting.co.za>
Message-ID: <1275168854.06.0.501933730348.issue8501@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Tarek, do we change the component to Distutils2?

If so, I?m willing to give this a try.

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8501>
_______________________________________

From report at bugs.python.org  Sat May 29 23:37:27 2010
From: report at bugs.python.org (Zack Goldstein)
Date: Sat, 29 May 2010 21:37:27 +0000
Subject: [issue7962] Demo/ directory needs to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1275169047.23.0.38945966767.issue7962@psf.upfronthosting.co.za>


Zack Goldstein <goldsz at gmail.com> added the comment:

I'm assuming tested means "run", and that a good demo is one that "works" for some nominal input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Sun May 30 01:30:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 29 May 2010 23:30:31 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

When installing Visual Studio 2008 SP1 on a Windows Vista x64 system, the installer registers the various registry keys under

Software\Wow6432Node\Microsoft\VisualStudio\9.0\

rather than

Software\Microsoft\VisualStudio\9.0\

This is due to some redirection MS is applying to registry names when running 32-bit apps (such as the VS2008 installer) on 64-bit Windows:

http://support.microsoft.com/kb/896459

Since the tools in msvc9compiler.py rely on the registry to find the various dirs, batch files and tools, these operations fail.

A simple solution is to just update the globals at the top of the file to:

VS_BASE = r"Software\Wow6432Node\Microsoft\VisualStudio\%0.1f"
WINSDK_BASE = r"Software\Wow6432Node\Microsoft\Microsoft SDKs\Windows"
NET_BASE = r"Software\Wow6432Node\Microsoft\.NETFramework"

but that would of course have to be done with some extra checks to not break these settings on other Windows systems.

I'm not sure whether this is specific to Windows Vista or also occurs on Windows 7.

----------
assignee: tarek
components: Distutils
keywords: 64bit
messages: 106745
nosy: lemburg, tarek
priority: normal
severity: normal
status: open
title: msvc9compiler.py: find_vcvarsall() doesn't work with VS2008 on Windows x64
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Sun May 30 02:53:54 2010
From: report at bugs.python.org (Longpoke)
Date: Sun, 30 May 2010 00:53:54 +0000
Subject: [issue8855] Shelve documentation lacks security warning
In-Reply-To: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>
Message-ID: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>


New submission from Longpoke <longpoke at gmail.com>:

Loading a shelve can cause arbitrary code to be executed [1] and other black magic (because it's backed by Pickle). Shouldn't there be a big fat warning at the top of the shelve documentation page?

Unless you're like me and assume anything to do with serialization in any language is insecure until proved otherwise, you aren't going to intuitively think there is anything wrong with "unshelving" untrusted data (unless you already know that Pickle is insecure).

1. http://nadiana.com/python-pickle-insecure#comment-261

----------
assignee: docs at python
components: Documentation
messages: 106746
nosy: docs at python, q94IjzUfnNoyv4c75mMw
priority: normal
severity: normal
status: open
title: Shelve documentation lacks security warning

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8855>
_______________________________________

From report at bugs.python.org  Sun May 30 02:54:51 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sun, 30 May 2010 00:54:51 +0000
Subject: [issue8470] Let cmd.cmd.intro be unicode friendly
In-Reply-To: <1271777349.17.0.192920763608.issue8470@psf.upfronthosting.co.za>
Message-ID: <1275180891.75.0.0742582150242.issue8470@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8470>
_______________________________________

From report at bugs.python.org  Sun May 30 08:07:41 2010
From: report at bugs.python.org (jroach)
Date: Sun, 30 May 2010 06:07:41 +0000
Subject: [issue8849] python.exe problem with cvxopt
In-Reply-To: <1275140884.5.0.432808728378.issue8849@psf.upfronthosting.co.za>
Message-ID: <4C0200A5.7000306@internode.on.net>


jroach <jroach at internode.on.net> added the comment:

Brian,
I am an engineer who makes significant use of Python, not a computer 
professional. I hope that I communicate the right information. The 
operating system is Windows XP Professional. The problem encountered was 
that a python program invoking cvxopt, that ran perfectly well with 
Python25, crashed with Python26 and (without request) generated a 
response from Visual Studio to the effect that python.exe encountered an 
access violation writing location 0x9b0b80c8. (The full message was 
'Unhandled exception  at 0x01de5607 in python.exe:0xC0000005: Access  
violation writing location 0x9b0b80c8. The c-code segment displayed by 
the debugger was (file: crt0dat.c):
  /*
         * walk the table of function pointers from the bottom up, until
         * the end is encountered.  Do not skip the first entry.  The 
initial
         * value of pfbegin points to the first valid entry.  Do not try to
         * execute what pfend points to.  Only entries before pfend are 
valid.
         */
        while ( pfbegin < pfend )
        {
            /*
             * if current table entry is non-NULL, call thru it.
             */
            if ( *pfbegin != NULL )
                (**pfbegin)();
            ++pfbegin;
        }
}

/***
* static int  _initterm_e(_PIFV * pfbegin, _PIFV * pfend) - call entries in
*       function pointer table, return error code on any failure
*
*Purpose:
*       Walk a table of function pointers in the same way as _initterm, but
*       here the functions return an error code.  If an error is 
returned, it
*       will be a nonzero value equal to one of the _RT_* codes.
*
*Entry:
The call stack line was: >    msvcr90.dll!_initterm(void (void)* * 
pfbegin=0x00000002, void (void)* * pfend=0x00993148)  Line 903    C
I do not have the necessary knowledge to interpret these data.
This Python26 problem occurs with every execution under both Idle and 
Editra.

jroach
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8849>
> _______________________________________
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8849>
_______________________________________

From report at bugs.python.org  Sun May 30 08:12:58 2010
From: report at bugs.python.org (David Kirkby)
Date: Sun, 30 May 2010 06:12:58 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275199978.2.0.649942963769.issue8852@psf.upfronthosting.co.za>


Changes by David Kirkby <david.kirkby at onetel.net>:


Removed file: http://bugs.python.org/file17497/socketmodule.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sun May 30 08:35:32 2010
From: report at bugs.python.org (David Kirkby)
Date: Sun, 30 May 2010 06:35:32 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1275201332.13.0.672253613242.issue8852@psf.upfronthosting.co.za>


David Kirkby <david.kirkby at onetel.net> added the comment:

I'd made a mistake when manually applying your patch, although my mistake made no practical difference. I'm attaching a corrected patch, which has all the changes needed to get this to build on OpenSolaris. It basically only checks for things before trying to compile with them, so it should be safe (and desirable) on any platform. 

I've not checked this on OpenSolaris on the SPARC hardware, though the use of OpenSolaris on SPARC hardware is very rare I believe. I' 99% sure that _socket builds ok on Solaris 10 on SPARC without any changes from the 2.6.4 source (I've not tried with 2.6.5) 

Dave

----------
Added file: http://bugs.python.org/file17498/socketmodule.c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Sun May 30 08:56:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 30 May 2010 06:56:25 +0000
Subject: [issue8829] IDLE editior not opening
In-Reply-To: <1274919139.94.0.215202967128.issue8829@psf.upfronthosting.co.za>
Message-ID: <1275202585.09.0.780969210014.issue8829@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

please ask help at python-help at python.org or comp.lang.python

----------
nosy: +orsenthil
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8829>
_______________________________________

From report at bugs.python.org  Sun May 30 09:25:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 30 May 2010 07:25:47 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275175831.39.0.913540756271.issue8854@psf.upfronthosting.co.za>
Message-ID: <1275204347.45.0.633196675669.issue8854@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This shouldn't be necessary. If a 32-bit Python looks into the registry, it will get automatically redirected to Wow6432Node. If a 64-bit Python looks into the registry, it shouldn't have any interest in values stored in Wow6432Node.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Sun May 30 11:20:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 30 May 2010 09:20:03 +0000
Subject: [issue8856] Error in ceval.c when buildind --without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I can?t build py3k HEAD without threads:

$ gcc -v 2>&1 | tail -2
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-1)

$ ./configure --without-threads
[snip snip]

$ make -s
Python/ceval.c: In function ?Py_AddPendingCall?:
Python/ceval.c:622: error: request for member ?_value? in something not a structure or union
Python/ceval.c:622: warning: type defaults to ?int? in declaration of ?new_val?
Python/ceval.c:622: error: request for member ?_value? in something not a structure or union
Python/ceval.c:622: error: request for member ?_value? in something not a structure or union
Python/ceval.c:622: error: memory input 1 is not directly addressable
Python/ceval.c: In function ?Py_MakePendingCalls?:
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: warning: type defaults to ?int? in declaration of ?new_val?
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: warning: type defaults to ?int? in declaration of ?result?
Python/ceval.c:635: error: request for member ?_value? in something not a structure or union
Python/ceval.c:648: error: request for member ?_value? in something not a structure or union
Python/ceval.c:648: warning: type defaults to ?int? in declaration of ?new_val?
Python/ceval.c:648: error: request for member ?_value? in something not a structure or union
Python/ceval.c:648: error: request for member ?_value? in something not a structure or union
Python/ceval.c:635: error: memory input 1 is not directly addressable
Python/ceval.c:648: error: memory input 1 is not directly addressable
Python/ceval.c: In function ?PyEval_EvalFrameEx?:
Python/ceval.c:1255: error: request for member ?_value? in something not a structure or union
Python/ceval.c:1255: warning: type defaults to ?int? in declaration of ?result?
Python/ceval.c:1255: error: request for member ?_value? in something not a structure or union
Python/ceval.c:1279: error: request for member ?_value? in something not a structure or union
Python/ceval.c:1279: warning: type defaults to ?int? in declaration of ?result?
Python/ceval.c:1279: error: request for member ?_value? in something not a structure or union
make: *** [Python/ceval.o] Erreur 1

It?s my first build failure report. What other information is needed?

----------
components: Build
messages: 106751
nosy: merwok
priority: normal
severity: normal
status: open
title: Error in ceval.c when buildind --without-threads
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8856>
_______________________________________

From report at bugs.python.org  Sun May 30 11:24:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 30 May 2010 09:24:42 +0000
Subject: [issue962772] when both maintainer and author provided,
	author discarded
Message-ID: <1275211482.57.0.675110004179.issue962772@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Tarek, should we change component to Distutils2?

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue962772>
_______________________________________

From report at bugs.python.org  Sun May 30 11:25:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 30 May 2010 09:25:38 +0000
Subject: [issue8856] Error in ceval.c when building --without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275211538.26.0.468885532269.issue8856@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Error in ceval.c when buildind --without-threads -> Error in ceval.c when building --without-threads

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8856>
_______________________________________

From report at bugs.python.org  Sun May 30 11:34:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 30 May 2010 09:34:09 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1275212049.04.0.803201207695.issue8623@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Same with gcc 4.4.4, in socket and another file:

Modules/_multiprocessing/multiprocessing.c: In function ?multiprocessing_sendfd?:
Modules/_multiprocessing/multiprocessing.c:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
Modules/_multiprocessing/multiprocessing.c: In function ?multiprocessing_recvfd?:
Modules/_multiprocessing/multiprocessing.c:168: warning: dereferencing type-punned pointer will break strict-aliasing rules

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8623>
_______________________________________

From report at bugs.python.org  Sun May 30 12:11:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 May 2010 10:11:33 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275214293.25.0.0231055101501.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

D'oh (again!)

[Mark]
> Really the coercion for complex types should have been removed at some
> point in the 2.x series

which of course, it was, in issue 5211.  And we should have caught the richcompare coercion in that issue.  So I apologise:  getting rid of the PyNumber_CoerceEx call was the right thing to do---we should have already done that in issue 5211.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sun May 30 12:26:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 May 2010 10:26:59 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275215219.82.0.699546642794.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Meador, I obviously haven't been thinking clearly about this.

Can you think of any reason that we shouldn't just copy the py3k implementation of complex_richcompare wholesale to trunk, with the single modification of replacing "if (PyLong_Check(w))" with "if (PyInt_Check(w) || PyLong_Check(w))"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sun May 30 13:41:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 30 May 2010 11:41:26 +0000
Subject: [issue8854] msvc9compiler.py: find_vcvarsall() doesn't work with
	VS2008 on Windows x64
In-Reply-To: <1275204347.45.0.633196675669.issue8854@psf.upfronthosting.co.za>
Message-ID: <4C024EE1.5020302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> This shouldn't be necessary. If a 32-bit Python looks into the registry, it will get automatically redirected to Wow6432Node. If a 64-bit Python looks into the registry, it shouldn't have any interest in values stored in Wow6432Node.

Perhaps I wasn't clear:

The VS2008 installer as well as the most of VS tool chain appear
to be 32-bit binaries and thus writes its keys and values into
Software\Wow6432Node\Windows\.

If you then run a 64-bit Python binary, it won't find the keys
under the regular Software\Windows\ reg path.

BTW: This was a fresh Vista and VS2008 installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8854>
_______________________________________

From report at bugs.python.org  Sun May 30 14:13:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 May 2010 12:13:31 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1275221611.6.0.61190500587.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r78280 didn't remove the implicit coercion for rich comparisons;  that's now been done in r81606.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun May 30 14:31:55 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 30 May 2010 12:31:55 +0000
Subject: [issue8784] tarfile/Windows: Don't use mbcs as the default encoding
In-Reply-To: <1274491335.43.0.732437213128.issue8784@psf.upfronthosting.co.za>
Message-ID: <1275222715.84.0.257698716888.issue8784@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

My expertise on Windows is rather limited, but as far as I understand the issue, I consider this a reasonable idea.
I think it is impossible to find a perfect default encoding, and utf-8 seems to be the best bet with regard to portability. IIRC most of the archivers on the Windows machines I have access to use latin-1, but I don't think that latin-1 is a suitable default value. I don't know much about Windows internals and have no idea what mbcs really is, but it is actually not available on other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8784>
_______________________________________

From report at bugs.python.org  Sun May 30 14:40:09 2010
From: report at bugs.python.org (chuchiperriman)
Date: Sun, 30 May 2010 12:40:09 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1275223209.33.0.184347942845.issue8797@psf.upfronthosting.co.za>


chuchiperriman <chuchiperriman at gmail.com> added the comment:

The same problem for me, it tries to authenticate infinite times if the user/password are incorrect

----------
nosy: +chuchiperriman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8797>
_______________________________________

From report at bugs.python.org  Sun May 30 15:20:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 May 2010 13:20:04 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275225604.21.0.0637287625776.issue8748@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, this is now fixed in trunk in r81610, using something closer to your original patch.

Thanks for all your help with this!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sun May 30 16:29:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 May 2010 14:29:53 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275229793.05.0.00131827153523.issue8845@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a complete patch, including documentation.  I tweaked Shashwat's unit test a bit, and added one to make sure the attribute is read only.

I'll apply this soonish if there are no objections.

----------
assignee:  -> r.david.murray
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file17499/sqlite3_in_transaction.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sun May 30 16:33:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 May 2010 14:33:08 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275229988.65.0.665635759965.issue8845@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file17499/sqlite3_in_transaction.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sun May 30 16:33:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 May 2010 14:33:49 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1275230029.12.0.918879279468.issue8845@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file17500/sqlite3_in_transaction.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sun May 30 16:37:29 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 30 May 2010 14:37:29 +0000
Subject: [issue8856] Error in ceval.c when building --without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275230249.64.0.970230369856.issue8856@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Confirmed on Mac OSX.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8856>
_______________________________________

From report at bugs.python.org  Sun May 30 16:39:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 14:39:43 +0000
Subject: [issue8856] Error in ceval.c when building --without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275230383.98.0.966136979152.issue8856@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8856>
_______________________________________

From report at bugs.python.org  Sun May 30 16:42:56 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 30 May 2010 14:42:56 +0000
Subject: [issue8856] Error in ceval.c when building --without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275230576.93.0.714935230636.issue8856@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Sorry, forgot the compiler and OS version:

   i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
   Mac OSX 10.5.8

S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8856>
_______________________________________

From report at bugs.python.org  Sun May 30 16:50:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 14:50:10 +0000
Subject: [issue8856] Error in ceval.c when building --without-threads
In-Reply-To: <1275211203.78.0.734042112342.issue8856@psf.upfronthosting.co.za>
Message-ID: <1275231010.44.0.0189540474491.issue8856@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81612.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8856>
_______________________________________

From report at bugs.python.org  Sun May 30 17:56:19 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 30 May 2010 15:56:19 +0000
Subject: [issue8446] buildbot: DeprecationWarning not raised for icglue
	(test_py3kwarn.TestStdlibRemovals)
In-Reply-To: <1271628757.81.0.455065561336.issue8446@psf.upfronthosting.co.za>
Message-ID: <1275234979.51.0.00398825302341.issue8446@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The root cause of this test failure is that test_macos runs before test_py3kwarn.

That causes MacOS to be imported before test_py3k runs and that results in not raising the py3k warning by the time test_py3kwarn runs.

I propose removing MacOS from the list of modules that test_py3kwarn tests for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8446>
_______________________________________

From report at bugs.python.org  Sun May 30 18:45:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 30 May 2010 16:45:39 +0000
Subject: [issue8853] getaddrinfo should accept port of type long
In-Reply-To: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>
Message-ID: <1275237939.38.0.292244861333.issue8853@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The attached patch should fix the problem.  I'm not sure how to test it, though:  the socket module currently seems to have exactly 0 tests for socket.getaddrinfo.

----------
keywords: +patch
nosy: +mark.dickinson
Added file: http://bugs.python.org/file17501/issue8853.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8853>
_______________________________________

From report at bugs.python.org  Sun May 30 18:58:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 16:58:11 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

socket.getaddrinfo has no tests at all. This should be fixed.

----------
components: Library (Lib), Tests
messages: 106767
nosy: pitrou
priority: high
severity: normal
status: open
title: socket.getaddrinfo needs tests
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/issue8857>
_______________________________________

From report at bugs.python.org  Sun May 30 18:58:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 16:58:26 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275238706.48.0.385394392195.issue8857@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun, giampaolo.rodola, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sun May 30 19:04:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 17:04:39 +0000
Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6
	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems socket.getaddrinfo gives wrong results for IPv6 address under py3k:

>>> pprint.pprint(socket.getaddrinfo("www.python.org", 0))
[(2, 1, 6, '', ('82.94.164.162', 0)),
 (2, 2, 17, '', ('82.94.164.162', 0)),
 (2, 3, 0, '', ('82.94.164.162', 0)),
 (10, 1, 6, '', (10, b'\x00\x00\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r')),
 (10, 2, 17, '', (10, b'\x00\x00\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r')),
 (10, 3, 0, '', (10, b'\x00\x00\x00\x00\x00\x00 \x01\x08\x88 \x00\x00\r'))]

The results given by 2.x make much more sense:
>>> pprint.pprint(socket.getaddrinfo("www.python.org", 0))
[(2, 1, 6, '', ('82.94.164.162', 0)),
 (2, 2, 17, '', ('82.94.164.162', 0)),
 (2, 3, 0, '', ('82.94.164.162', 0)),
 (10, 1, 6, '', ('2001:888:2000:d::a2', 0, 0, 0)),
 (10, 2, 17, '', ('2001:888:2000:d::a2', 0, 0, 0)),
 (10, 3, 0, '', ('2001:888:2000:d::a2', 0, 0, 0))]

----------
messages: 106768
nosy: pitrou
priority: high
severity: normal
status: open
title: socket.getaddrinfo returns wrong results for IPv6 addresses
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8858>
_______________________________________

From report at bugs.python.org  Sun May 30 19:04:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 17:04:50 +0000
Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6
	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275239090.88.0.176470485936.issue8858@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun, giampaolo.rodola, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8858>
_______________________________________

From report at bugs.python.org  Sun May 30 19:07:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 17:07:29 +0000
Subject: [issue8853] getaddrinfo should accept port of type long
In-Reply-To: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>
Message-ID: <1275239249.1.0.843924585865.issue8853@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See issue8857 for the tests issue.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8853>
_______________________________________

From report at bugs.python.org  Sun May 30 19:23:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 17:23:19 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275240199.16.0.300961544113.issue8857@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It also needs better documentation, by the way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sun May 30 20:01:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 18:01:47 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275242507.18.0.592235734415.issue8857@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a possible doc patch for getaddrinfo(). Comments?

----------
keywords: +patch
Added file: http://bugs.python.org/file17502/doc-getaddrinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sun May 30 20:04:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 18:04:31 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275242671.97.0.785859614119.issue8857@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file17502/doc-getaddrinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sun May 30 20:04:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 18:04:37 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275242677.93.0.195979784093.issue8857@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file17503/doc-getaddrinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Sun May 30 20:10:37 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 30 May 2010 18:10:37 +0000
Subject: [issue8748] integer-to-complex comparisons give incorrect results
In-Reply-To: <1274179036.3.0.754840788913.issue8748@psf.upfronthosting.co.za>
Message-ID: <1275243037.26.0.644575165815.issue8748@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

[Mark]
> Can you think of any reason that we shouldn't just copy the py3k 
> implementation ...

Not that I can think of.  Like you pointed out, we should have removed the  coercion from the rich comparison when fixing issue 5211.

> Thanks for all your help with this!

No problem!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________

From report at bugs.python.org  Sun May 30 20:54:14 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sun, 30 May 2010 18:54:14 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

When the variable label is equal to '\xc5\xa0 Z\nX W'
this line sequence
label = " ".join(label.split())
label = unicode(label)
results in:
7347: ERROR: gramps.py: line 138: Unhandled exception
Traceback (most recent call last):
  File "C:\Program Files (x86)\gramps\gui\views\listview.py", line 660, in row_changed
    self.uistate.modify_statusbar(self.dbstate)
  File "C:\Program Files (x86)\gramps\DisplayState.py", line 521, in modify_statusbar
    name, obj = navigation_label(dbstate.db, nav_type, active_handle)
  File "C:\Program Files (x86)\gramps\Utils.py", line 1358, in navigation_label
    label = unicode(label)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data

While this line sequence:
label = unicode(label)
label = " ".join(label.split())
gives correct result and no error.

With the error the variable label changes from
'\xc5\xa0 Z\nX W'
to
'\xc5 Z X W'
by the line:
label = " ".join(label.split())
Note '\xa0' has been dropped, interpreted as "whitespace"?
This happens on Windows. It works perfectly well on Linux.

----------
components: Library (Lib)
messages: 106773
nosy: PeterL
priority: normal
severity: normal
status: open
title: split() splits on non whitespace char when ther is no separator given.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Sun May 30 21:12:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 May 2010 19:12:36 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275246756.15.0.893458000522.issue8859@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Both on Linux and Windows I get:
>>> '\xa0'.isspace()
False
>>> u'\xa0'.isspace()
True

The Unicode char u'\xa0' is U+00A0 NO-BREAK SPACE, so unicode.split correctly considers it a whitespace.
However '\xa0' is not a whitespace, so str.split ignores it.
The correct solution is to convert your string to Unicode and then split.
I'd close this as invalid but I'd like you to confirm that the example I posted and that 'split' return the same result on both Linux and Windows before doing so (the fact that on Linux works it's probably caused by something else -- e.g. the label is already Unicode).

----------
nosy: +ezio.melotti
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Sun May 30 21:13:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 19:13:24 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275246804.33.0.630242985133.issue8859@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What do you mean, "works perfectly well under Linux"?
The error also happens under Linux here, and is expected: you can't call unicode() without an encoding and expect it to decode properly non-ASCII chars (and \xa0 is a non-ASCII char).

----------
nosy: +pitrou
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Sun May 30 21:16:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 19:16:24 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275246984.13.0.121638532362.issue8859@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, and I agree with Ezio, this is most likely not a bug at all and should probably be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Sun May 30 21:34:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 30 May 2010 19:34:57 +0000
Subject: [issue8807] poplib should support SSL contexts
In-Reply-To: <1274717453.42.0.117034220477.issue8807@psf.upfronthosting.co.za>
Message-ID: <1275248097.37.0.484324954209.issue8807@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's the problem mentioned by Ezio: it breaks compatibility if someone passed a timeout to POP3_SSL by position (rather than by name).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8807>
_______________________________________

From report at bugs.python.org  Sun May 30 22:03:48 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sun, 30 May 2010 20:03:48 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275249828.96.0.479501843487.issue8859@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

I am not sure I can follow you. I will try to be more specific.

The test string consists originally of one character; the Czech ?.

1. On Linux with Python 2.6.4
1.1 If I keep the original code line order:
label = obj.get()
print type(label), repr(label)
label = " ".join(label.split())
print type(label), repr(label)
label = unicode(label)
if len(label) > 40:
    label = label[:40] + "..."

Both lines print type(label), repr(label) gives:
<type 'str'> '\xc5\xa0'

1.2 If I change order and take the unicode conversion first:
label = obj.get()
label = unicode(label)
print type(label), repr(label)
label = " ".join(label.split())
print type(label), repr(label)
if len(label) > 40:
    label = label[:40] + "..."

Both lines print type(label), repr(label) gives:
<type 'unicode'> u'\u0160'

2. On Windows with Python 2.6.5
2.1 The original code line order:
The lines print type(label), repr(label) gives
<type 'str'> '\xc5\xa0'
<type 'str'> '\xc5'
 8217: ERROR: gramps.py: line 138: Unhandled exception
 ....

2.2 If I change order and take the unicode conversion first:
Both lines print type(label), repr(label) gives:
<type 'unicode'> u'\u0160'

3.
If I use this little code:
# -*- coding: utf-8 -*-
label = '?'
print type(label), repr(label)
label = " ".join(label.split())
print type(label), repr(label)
I get 
<type 'str'> '\xc5\xa0'
<type 'str'> '\xc5\xa0'
on both Linux and Windows.

The examples above under 1. and 2. comes from an application, Gramps.

There is still something I don't understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Sun May 30 22:20:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 May 2010 20:20:54 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275250854.2.0.79229973458.issue8859@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the problem is in the default encoding used when you call unicode() without specifying any encoding.
>>> '\xc5\xa0'.decode('iso-8859-1').split()
[u'\xc5']
>>> '\xc5\xa0'.decode('utf-8').split()
[u'\u0160']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Sun May 30 22:38:25 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 30 May 2010 20:38:25 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1275251905.96.0.547964877009.issue7946@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file17356/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 30 22:50:24 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 30 May 2010 20:50:24 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1275252624.99.0.486096887382.issue7946@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Updated bfs.patch with BSD license and copyright notice.

! Current version patches cleanly and builds with Python revision svn r81201.

Issue 7946 and proposed patches were put on hold indefinitely following this python-dev discussion: http://mail.python.org/pipermail/python-dev/2010-May/100115.html

I would like to thank the Python developer community and in particular David and Antoine for a most interesting ride.

Any party interested in sponsoring further development or porting patch to Python 2.x is welcome to contact me directly at nir at winpdb.org

Nir

----------
Added file: http://bugs.python.org/file17504/bfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Sun May 30 23:02:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 30 May 2010 21:02:04 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1275253324.12.0.404763614248.issue7983@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Hye-Shik, could you please comment on this ?

The Windows version appears to replace private use code points with CJK compatibility idiographs, ie. uses standard Unicode code points rather than private escape code points (for round-trip safety).

----------
assignee:  -> hyeshik.chang
nosy: +hyeshik.chang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Sun May 30 23:16:32 2010
From: report at bugs.python.org (Andrew Grover)
Date: Sun, 30 May 2010 21:16:32 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1275254192.08.0.0452571089517.issue6560@psf.upfronthosting.co.za>


Changes by Andrew Grover <andy.grover at gmail.com>:


----------
nosy: +Andrew.Grover

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Sun May 30 23:44:35 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 30 May 2010 21:44:35 +0000
Subject: [issue7946] Convoy effect with I/O bound threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1275255875.68.0.823881104436.issue7946@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for all your work Nir!  I personally think the BFS approach is the best we've seen yet for this problem!

Having read the thread you linked to in full (ignoring the tagents  bikeshedding and mudslinging that went on there), it sounds like the general consensus is that we should take thread scheduling changes slowly and let the existing new implementation bake in the 3.2 release.  That puts this issue as a possibility for 3.3 if users demonstrate real world application problems in 3.2.

(personally I'd say it is already obvious that there are problems an wde should go ahead with your BFS based approach but realistically the we're still better off in 3.2 than we were in 3.1 and 2.x as is)

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon May 31 01:26:52 2010
From: report at bugs.python.org (Sebastian)
Date: Sun, 30 May 2010 23:26:52 +0000
Subject: [issue8787] warnings inside PyRun_SimpleString() display argv[1]
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1275262012.78.0.0873379850503.issue8787@psf.upfronthosting.co.za>


Sebastian <python.10.webmaster at spamgourmet.com> added the comment:

any news on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Mon May 31 02:42:56 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 31 May 2010 00:42:56 +0000
Subject: [issue8787] warnings inside PyRun_SimpleString() display argv[1]
In-Reply-To: <1274536832.39.0.220188636264.issue8787@psf.upfronthosting.co.za>
Message-ID: <1275266576.55.0.572512610951.issue8787@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

First of all, your patch needs a test.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8787>
_______________________________________

From report at bugs.python.org  Mon May 31 06:13:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 May 2010 04:13:09 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275279189.39.0.912757069501.issue8859@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I also agree this should be closed.

----------
nosy: +rhettinger
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Mon May 31 08:51:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 May 2010 06:51:30 +0000
Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6
	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275288690.44.0.227227838244.issue8858@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What operating system is this on? What exact Python version are you using?

I can't reproduce this with r81614 on Linux.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8858>
_______________________________________

From report at bugs.python.org  Mon May 31 09:14:00 2010
From: report at bugs.python.org (Peter Landgren)
Date: Mon, 31 May 2010 07:14:00 +0000
Subject: [issue8859] split() splits on non whitespace char when ther is no
	separator given.
In-Reply-To: <1275245654.33.0.885682282706.issue8859@psf.upfronthosting.co.za>
Message-ID: <1275290040.37.0.344822027079.issue8859@psf.upfronthosting.co.za>


Peter Landgren <peter.talken at telia.com> added the comment:

So as a summary to what Ezio Melotti said:
I should always specify encoding when calling split() to be sure nothing nasty happens? (Belive Ezio Melotti meant "calling split()" not "calling unicode()" in his last answer?)

Thanks for pointing this out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8859>
_______________________________________

From report at bugs.python.org  Mon May 31 11:08:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 May 2010 09:08:37 +0000
Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6
	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275296917.29.0.530553778356.issue8858@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not seeing this either, on SuSE Linux 10.3/amd64:

Python 3.2a0 (py3k:81616, May 31 2010, 10:05:21)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
[55247 refs]
>>> socket.getaddrinfo("www.python.org", 0)
[(2, 1, 6, '', ('82.94.164.162', 0)), (2, 2, 17, '', ('82.94.164.162', 0)), (2, 3, 0, '', ('82.94.164.162', 0)), (10, 1, 6, '', ('2001:888:2000:d::a2', 0, 0, 0)), (10, 2, 17, '', ('2001:888:2000:d::a2', 0, 0, 0)), (10, 3, 0, '', ('2001:888:2000:d::a2', 0, 0, 0))]
[58509 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8858>
_______________________________________

From report at bugs.python.org  Mon May 31 12:36:16 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 31 May 2010 10:36:16 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1275302176.47.0.042971059988.issue1777412@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Mon May 31 12:50:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 10:50:18 +0000
Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6
	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275303018.64.0.479243426805.issue8858@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is under Mandriva Linux 2010.1 (release candidate).

Python 3.2a0 (py3k:81616, May 31 2010, 12:40:34) 
[GCC 4.4.3] on linux2

It seems ENABLE_IPV6 isn't defined:

$ grep IPV6 pyconfig.h
32:/* #undef ENABLE_IPV6 */

Yet AF_INET6 is defined and has the same value as returned by socket.getaddrinfo():

>>> socket.AF_INET6
10

I'll try to ./configure again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8858>
_______________________________________

From report at bugs.python.org  Mon May 31 12:56:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 10:56:30 +0000
Subject: [issue8858] socket.getaddrinfo returns wrong results for IPv6
	addresses
In-Reply-To: <1275239079.49.0.0162981325247.issue8858@psf.upfronthosting.co.za>
Message-ID: <1275303390.37.0.113557386459.issue8858@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem was solved after running configure again. Sorry.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8858>
_______________________________________

From report at bugs.python.org  Mon May 31 14:16:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 May 2010 12:16:03 +0000
Subject: [issue1491] BaseHTTPServer incorrectly implements response code 100
In-Reply-To: <1195822360.07.0.215272908737.issue1491@psf.upfronthosting.co.za>
Message-ID: <1275308163.26.0.049759456422.issue1491@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1491>
_______________________________________

From report at bugs.python.org  Mon May 31 14:16:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 31 May 2010 12:16:20 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1275308180.44.0.170160927219.issue1777412@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Mon May 31 17:31:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 May 2010 15:31:10 +0000
Subject: [issue8793] IDLE crashes on opening invalid file
In-Reply-To: <1274607720.78.0.880248664053.issue8793@psf.upfronthosting.co.za>
Message-ID: <1275319870.21.0.0144584893147.issue8793@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

When running IDLE in a console, I get the error:

Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\prod\python\lib\lib-tk\Tkinter.py", line 1410, in __call__
    return self.func(*args)
  File "c:\prod\python\lib\idlelib\MultiCall.py", line 150, in handler
    r = l[i](event)
  File "c:\prod\python\lib\idlelib\ScriptBinding.py", line 140, in run_module_event
    code = self.checksyntax(filename)
  File "c:\prod\python\lib\idlelib\ScriptBinding.py", line 99, in checksyntax
    return compile(source, filename, "exec")
ValueError: invalid \x escape

The crash in "Bug#2" is certainly because pythonw.exe has no console, so sys.stdout blocks on the first flush(), after 4096 bytes of output.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8793>
_______________________________________

From report at bugs.python.org  Mon May 31 18:23:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 16:23:20 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1275323000.06.0.641713696512.issue7879@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

- 26backport committed in r81618.
- merged to release31-maint in r81619.

The skipIf patch blocked from release26-maint (skipIf is new in 2.7) and merged into release31-maint in r81620.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Mon May 31 18:39:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 16:39:41 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>From issue1289118, msg106389:

"""
>>> from datetime import timedelta as d
>>> [d(microseconds=i + .5)//d.resolution for i in range(-10,10)]
[-10, -9, -8, -7, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Should this be considered a bug?

For comparison,

>>> [d.resolution*(i+0.5)//d.resolution for i in range(-10,10)]
[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

and
>>> [round(i+0.5) for i in range(-10,10)]
[-10, -8, -8, -6, -6, -4, -4, -2, -2, 0, 0, 2, 2, 4, 4, 6, 6, 8, 8, 10]

I checked the documentation and while it says: "If any argument is a float and there are fractional microseconds, the fractional microseconds left over from all arguments are combined and their sum is rounded to the nearest microsecond." it does not specify how half-integers should be handled.

While it may not be a bug in strict sense, it looks like the code in question can be improved. 
"""

----------
assignee: belopolsky
messages: 106793
nosy: belopolsky, haypo, mark.dickinson, mcherm, rhettinger, stutzbach, tim_one
priority: normal
severity: normal
stage: unit test needed
status: open
title: Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Mon May 31 18:45:45 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 31 May 2010 16:45:45 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275324345.57.0.993195617803.issue8857@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

About the doc patch: I like the word "Resolves" more than "Translate".  "Resolves" implies possible network activity to me.  "Translate" sounds like it's just a change in representation.  Of course, things like `AI_NUMERICHOST` complicate things, since there may not actually be any network activity.

The rest seems fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Mon May 31 19:07:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 17:07:10 +0000
Subject: [issue8857] socket.getaddrinfo needs tests
In-Reply-To: <1275238691.69.0.194519582018.issue8857@psf.upfronthosting.co.za>
Message-ID: <1275325630.29.0.203991229639.issue8857@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the comments. Other functions use "translate" too (gethostbyname, getservbyname, etc.), so I preferred to keep it for consistency. I've now committed the doc patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8857>
_______________________________________

From report at bugs.python.org  Mon May 31 19:14:56 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 31 May 2010 17:14:56 +0000
Subject: [issue6771] Curses.wrapper: documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1275326096.42.0.769466153957.issue6771@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

I think, since curses.wrapper is actually a function (and module named curses.wrapper cannot be trivially accessed), we can just modify docs, stripping out any mentions of module, instead documenting the function.

We can leave the module 'curses.wrapper' and line 'from curses.wrapper import wrapper' in its current state, as implementation detail.

Also, this is not backward incompatible in any case.

Patch added.

----------
keywords: +patch
nosy: +july
Added file: http://bugs.python.org/file17505/curses-wrapper-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Mon May 31 19:27:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 17:27:52 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1275326872.41.0.499941794862.issue6560@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Would you like to upload your patch to http://codereview.appspot.com/? It would make reviewing easier.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon May 31 19:32:15 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 31 May 2010 17:32:15 +0000
Subject: [issue8861] curses.wrapper : unnessesary code
In-Reply-To: <1275327135.19.0.0185418659015.issue8861@psf.upfronthosting.co.za>
Message-ID: <1275327135.19.0.0185418659015.issue8861@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

wrapper() code in Lib/curses/wrapper.py
has an unnesesary line:

    res = None

This variable is not used anywhere else in wrapper().
Inspecting the history of trunk, we can see that it was used used as a result of applying func(), but later was replaced by another construction.

Patch added.

----------
components: Library (Lib)
files: curses-wrapper-cleanup.patch
keywords: patch
messages: 106798
nosy: july
priority: normal
severity: normal
status: open
title: curses.wrapper : unnessesary code
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17506/curses-wrapper-cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8861>
_______________________________________

From report at bugs.python.org  Mon May 31 20:23:59 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 31 May 2010 18:23:59 +0000
Subject: [issue8862] curses.wrapper does not restore terminal if
	curses.getkey() gets KeyboardInterrupt
In-Reply-To: <1275330239.59.0.0964939469403.issue8862@psf.upfronthosting.co.za>
Message-ID: <1275330239.59.0.0964939469403.issue8862@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

Run test.py (below) in terminal, and interrupt it with Ctrl-C.

Result: terminal settings are not restored (checked with linux console and xterm, with Python 2.7 and 3.2).

# test.py
# Broke it with KeyboardInterrupt
import curses
def main(screen):
    k = screen.getkey()
curses.wrapper(main)
# Results are hardly readable due to the broken terminal.
# Something about KeyboardInterrupt

However, if getkey() is surrounded by try-except, behavior changes:

# test2.py
# Broke it with KeyboardInterrupt
import curses
def main2(screen):
    try:
        k = screen.getkey()
    except KeyboardInterrupt:
        raise
curses.wrapper(main2)
# Terminal is restored to its normal state.

In python3.2 test2.py results in traceback:

Traceback (most recent call last):
  File "test2.py", line 4, in main2
    k = screen.getkey()
_curses.error: no input

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test2.py", line 7, in <module>
    curses.wrapper(main2)
  File "/usr/local/lib/python3.2/curses/wrapper.py", line 44, in wrapper
    return func(stdscr, *args, **kwds)
  File "test2.py", line 4, in main2
    k = screen.getkey()
KeyboardInterrupt


In 2.7 it results only in the latest part of traceback:

Traceback (most recent call last):
  File "test2.py", line 7, in <module>
    curses.wrapper(main2)
  File "/usr/local/lib/python2.7/curses/wrapper.py", line 44, in wrapper
    return func(stdscr, *args, **kwds)
  File "test2.py", line 4, in main2
    k = screen.getkey()
KeyboardInterrupt


The problem is that instead of a single KeyboardInterrupt, two exceptions are raised: KeyboardInterrupt and _curses.error('no input').

Possible solution is to suppress _curses.error in this case (since it is less relevant than KeyboardInterrupt, IMO).

----------
components: Library (Lib)
messages: 106799
nosy: july
priority: normal
severity: normal
status: open
title: curses.wrapper does not restore terminal if curses.getkey() gets KeyboardInterrupt
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8862>
_______________________________________

From report at bugs.python.org  Mon May 31 21:01:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 19:01:15 +0000
Subject: [issue1289118] timedelta multiply and divide by floating point
Message-ID: <1275332475.97.0.43170683288.issue1289118@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r81625.  Fixed white space and added a note to "new in 3.2" section of the RST doc.

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1289118>
_______________________________________

From report at bugs.python.org  Mon May 31 21:01:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 May 2010 19:01:25 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached patch implements an handler for the signal SIGSEGV. It uses its own stack to be able to allocate memory on the stack (eg. call a function), even on stack overflow.

The patch requires sigaction() and sigaltstack() functions, but I didn't patched configure.in script. These functions are available on Linux, but should be available on other UNIX OSes.

segfault() signal handler supposes that the thread state is consistent (interp->frame chained list). It calls indirectly PyUnicode_EncodeUTF8() and so call PyBytes_FromStringAndSize() which allocates memory on the heap. It clears PyUnicode "defenc" attribute (the result of PyUnicode_EncodeUTF8()) to free directly the memory.

To test it, try some scripts in Lib/test/crashers/.

One example:
--------------------
$ ./python Lib/test/crashers/recursive_call.py
Fatal Python error: segmentation fault

Traceback (most recent call first):
  File "Lib/test/crashers/recursive_call.py", line 12, depth 15715
  File "Lib/test/crashers/recursive_call.py", line 12, depth 15714
  File "Lib/test/crashers/recursive_call.py", line 12, depth 15713
...
  File "Lib/test/crashers/recursive_call.py", line 12, depth 3
  File "Lib/test/crashers/recursive_call.py", line 12, depth 2
  File "Lib/test/crashers/recursive_call.py", line 9, depth 1
Segmentation fault
--------------------

----------
components: Interpreter Core
files: segfault_handler.patch
keywords: patch
messages: 106801
nosy: haypo
priority: normal
severity: normal
status: open
title: Segfault handler: display Python backtrace on segfault
versions: Python 3.2
Added file: http://bugs.python.org/file17507/segfault_handler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon May 31 21:09:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 19:09:08 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275332948.23.0.846341073094.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is a shorter example of inconsistent behavior:

>>> 0.5 * timedelta(microseconds=1)
datetime.timedelta(0)
>>> timedelta(microseconds=0.5)
datetime.timedelta(0, 0, 1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Mon May 31 21:10:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 May 2010 19:10:19 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1275333019.74.0.666431600586.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #3999: a similar patch to raise an exception on segfault. This patch was rejected because Python internal state may be corrupted, and we cannot guarantee that next instructions will be executed correctly.

This patch is safer because it just tries to display the backtrace and then exit.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon May 31 21:16:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 31 May 2010 19:16:33 +0000
Subject: [issue3999] Real segmentation fault handler
In-Reply-To: <1222737012.4.0.203589723568.issue3999@psf.upfronthosting.co.za>
Message-ID: <1275333393.9.0.463628072734.issue3999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> That's fine, but please provide a link to the new issue once you create it.

Done: issue #8863.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3999>
_______________________________________

From report at bugs.python.org  Mon May 31 21:23:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 19:23:22 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1275333802.65.0.351727454243.issue1100942@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Does this need to be brought up on python-dev for acceptance?

----------
nosy: +mark.dickinson
stage: unit test needed -> patch review
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Mon May 31 21:29:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 31 May 2010 19:29:10 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1275334150.87.0.423869749616.issue5023@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Mon May 31 21:42:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 May 2010 19:42:08 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275334928.25.0.932964742273.issue8860@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree it would be nice to fix this.  We could either (1) alter delta_new so that the final round uses round-to-nearest;  this would give the desired behaviour in most cases, but there would still be a small possibility of rounding going in the wrong direction as a result of accumulated errors in 'leftover_us'.  Or (2) rewrite delta_new to do correct rounding in all cases, by using integer arithmetic where necessary.

(2) seems like overkill to me.

For (1), it looks like it would be enough just to replace the round_to_long function with:

static long
round_to_long(double x)
{
    return (long)round(x);
}

Actually, at this point, one might as well just inline round_to_long.

Note that round_to_long is also called from datetime_from_timestamp.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Mon May 31 21:45:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 May 2010 19:45:15 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1275335115.02.0.140695232132.issue1100942@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This doesn't appear to be at all controversial;  I don't think it's necessary to consult python-dev.  (I haven't looked at the patch, though.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Mon May 31 21:49:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 May 2010 19:49:53 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275335393.89.0.0610478252016.issue8860@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Aargh!  No, I take that back.  round() also does round-half-away-from-zero, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Mon May 31 22:24:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 May 2010 20:24:24 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1275337464.04.0.518333018375.issue8860@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a first stab at a patch.  It still needs tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file17508/issue8860.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8860>
_______________________________________

From report at bugs.python.org  Mon May 31 22:40:00 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 31 May 2010 20:40:00 +0000
Subject: [issue8318] Deprecation of multifile inappropriate or incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1275338400.06.0.243091125338.issue8318@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

For the sake of completeness:  the Zope2 trunk and its current stable
branch now no longer use the multifile module, thanks to the following
patch:

 http://svn.zope.org/Zope/trunk/src/OFS/tests/testRanges.py?rev=110704&r1=110402&r2=110704

That diff might serve as fodder for updating the docs for the deprecation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8318>
_______________________________________

From report at bugs.python.org  Mon May 31 23:13:59 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 31 May 2010 21:13:59 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1275340439.72.0.750466102479.issue1692335@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

The attached patch adds Mark's examples to test_pickle as a failing test.

----------
nosy: +tseaver
Added file: http://bugs.python.org/file17509/issue1692335-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Mon May 31 23:29:12 2010
From: report at bugs.python.org (Philipp Gortan)
Date: Mon, 31 May 2010 21:29:12 +0000
Subject: [issue5023] Segfault in datetime.time.strftime("%z")
In-Reply-To: <1232556285.78.0.999173961019.issue5023@psf.upfronthosting.co.za>
Message-ID: <1275341352.59.0.262897814707.issue5023@psf.upfronthosting.co.za>


Philipp Gortan <mephinet at gmx.net> added the comment:

@belopolsky: unittest exists, 
/usr/lib/python2.6/test/test_datetime.py
as mentioned by the OP, this unittest reproduces
the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5023>
_______________________________________

From report at bugs.python.org  Mon May 31 23:42:26 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 31 May 2010 21:42:26 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

There is apparently a regression on ^/trunk with multiprocessing on solaris10-x86 today. (used to work a few weeks before)

cc -Kpic -OPT:Olimit=0 -g -DNDEBUG -O -IModules/_multiprocessing -I. -IInclude -I./Include -I/export/home/apy/rrun/build/activepyt
hon-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Include -I/export/home/apy/rrun/build/activepython-svn-trunk/buil
d/pyhg_trunk-solaris10-x86-hgtip27-rrun/python -c /export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c -o build/temp.solaris-2.10-i86pc-2.7/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.o
cc: Warning: illegal option -OPT:Olimit=0
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 126: undefined struct/union member: msg_control
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 126: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 127: undefined struct/union member: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 130: warning: implicit function declaration: CMSG_FIRSTHDR
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 130: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 134: improper member use: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 135: warning: implicit function declaration: CMSG_DATA
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 161: undefined struct/union member: msg_control
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 161: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 162: undefined struct/union member: msg_controllen
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 165: warning: improper pointer/integer combination: op "="
"/export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c", line 169: improper member use: msg_controllen
cc: acomp failed for /export/home/apy/rrun/build/activepython-svn-trunk/build/pyhg_trunk-solaris10-x86-hgtip27-rrun/python/Modules/_multiprocessing/multiprocessing.c

----------
components: Build, Library (Lib)
messages: 106813
nosy: srid
priority: normal
severity: normal
status: open
title: multiprocessing: undefined struct/union member: msg_control
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8864>
_______________________________________

From report at bugs.python.org  Mon May 31 23:58:40 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 31 May 2010 21:58:40 +0000
Subject: [issue8864] multiprocessing: undefined struct/union member:
	msg_control
In-Reply-To: <1275342146.08.0.266544809639.issue8864@psf.upfronthosting.co.za>
Message-ID: <1275343120.69.0.57901463825.issue8864@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Platforms affected:
  SunOS ginsu 5.10 Generic_125101-10 i86pc i386 i86pc
  SunOS nail 5.8 Generic_117350-55 sun4u sparc SUNW,Sun-Fire-280R

Compiler used:
bash-2.03$ which cc                
/opt/SUNWspro/bin//cc
bash-2.03$ cc -V   
cc: Sun C 5.7 2005/01/07
usage: cc [ options] files.  Use 'cc -flags' for details

This seems to have been introduced by fix for Issue1759169

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8864>
_______________________________________