From report at bugs.python.org  Wed Dec  1 00:11:08 2010
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Tue, 30 Nov 2010 23:11:08 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1291158668.04.0.0827646033424.issue1649329@psf.upfronthosting.co.za>


Shannon -jj Behrens <jjinux at users.sourceforge.net> added the comment:

Sorry, I just had a baby on Saturday.  Hence, I'm a bit late getting to this.  It might take me a couple weeks.

----------

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

From report at bugs.python.org  Wed Dec  1 00:24:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 23:24:49 +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: <1291159489.37.0.400747990884.issue8425@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Deferring to 3.3.

----------
priority: normal -> low
versions: +Python 3.3 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Dec  1 00:33:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 23:33:23 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1291160003.81.0.0104352921287.issue6422@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This does not conflict with the other proposed changes to timeit and it is in-line with Guido's desire that to expose useful parts currently buried in the command-line logic.

Amaury, you've shown an interest.  Would you like to apply it?

----------
assignee: rhettinger -> amaury.forgeotdarc
resolution:  -> accepted
versions:  -Python 2.7

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

From report at bugs.python.org  Wed Dec  1 00:37:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 23:37:26 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1291160246.84.0.137767454063.issue6594@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Antoine, what do you want to do with the one?  Without a good test case the OP's original issue is undiagnosable.

----------
assignee: rhettinger -> pitrou
versions: +Python 3.1

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

From report at bugs.python.org  Wed Dec  1 00:48:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 23:48:35 +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: <1291160915.22.0.464239394418.issue8425@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Any new logic should make maximum use of existing tools:

def __isub__(self, other)
    if len(other) > len(self)*8:
        other = self & other
    . . .
    # rest of isub unchanged

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

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

From report at bugs.python.org  Wed Dec  1 00:49:16 2010
From: report at bugs.python.org (Shawn)
Date: Tue, 30 Nov 2010 23:49:16 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1291160956.0.0.397581539531.issue6594@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

I specifically mentioned *SPARC* as the performance problem area, but the reply about "0.5s to dump" fails to mention on what platform they tested

My problem is not "undiagnosable".  I'll be happy to provide you with even more data files.  But I believe that there is a problem here on some architectures for reasons other than those of simple differences in single-threaded performance that could be accounted to processor architecture.

As an example of something that makes a noticeable difference on SPARC systems I've checked:

178     # could accelerate with writelines in some versions of Python, at
179     # a debuggability cost
180     for chunk in iterable:
181         fp.write(chunk)

Changing that to use writelines() is a significant win.  You go from over a million calls to write (for small bits as simple as a single character such as '{') to one single call to writelines() with an iterable.

The recursive call structure of the json code also adds significant overhead on some architectures.

What's "undiagnosable" here is the response to the issue I reported -- it provides no information about the platform that was tested or how the testing was done.

My testing was done by reading the attached file using json, and then timing the results of writing it back out (to /tmp mind you, which is memory-backed on my OS platform, so no disk I/O was involved, I've also checked writing to a cStringIO object).

----------

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

From report at bugs.python.org  Wed Dec  1 01:01:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 00:01:23 +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: <1291161683.4.0.687317394097.issue8743@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Daniel, do you have time to work on this one?

If so, go ahead an make setobject.c accept any instance of collections.Set and make the corresponding change to the ABCs:

    def __or__(self, other):
        if not isinstance(other, Set):
            return NotImplemented
        chain = (e for s in (self, other) for e in s)
        return self._from_iterable(chain)

The code in the attached prelim.patch has working C code isinstance(x, collections.Set), but the rest of the patch that applies is has not been tested.  It needs to be applied very carefully and thoughtfully because:
* internally, the self and other can get swapped on a binary call
* we can't make *any* assumptions about "other" (that duplicates have actually been eliminated or the the elements are even hashable).

The most reliable thing to do for the case where PyAnySet(obj) is False but isinstance(obj, collections.Set) is true is to call the named method such as s.union(other) instead of continuing with s.__or__ which was designed only with real sets in mind.

----------
assignee: rhettinger -> stutzbach

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

From report at bugs.python.org  Wed Dec  1 01:01:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 01 Dec 2010 00:01:31 +0000
Subject: [issue10591] test_os failure in refleak runs
In-Reply-To: <1291156126.42.0.381106886748.issue10591@psf.upfronthosting.co.za>
Message-ID: <1291161691.99.0.149106924174.issue10591@psf.upfronthosting.co.za>


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

Fixed in r86906. Split the shared setUp/tearDown into individual methods for each part.

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

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

From report at bugs.python.org  Wed Dec  1 01:04:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Dec 2010 00:04:01 +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: <1291161841.31.0.215573785428.issue8743@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Yes, I can take a stab at it.

----------

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

From report at bugs.python.org  Wed Dec  1 01:08:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 00:08: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: <1291162100.29.0.0766646745815.issue8743@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

No need to rush this for the beta.  It's a bug fix and can go in at any time.  The important thing is that we don't break the C code.  The __ror__ magic method would still need to do the right thing and the C code needs to defend against the interpreter swapping self and other.

----------

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

From report at bugs.python.org  Wed Dec  1 01:20:26 2010
From: report at bugs.python.org (Elias Zamaria)
Date: Wed, 01 Dec 2010 00:20:26 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>


New submission from Elias Zamaria <mikez302 at gmail.com>:

If I try to pretty-print an ordered dictionary, it doesn't show nicely. Instead of having each key-value pair on its own line, the whole thing shows up on one long line, which wraps many times and is hard to read.

I can provide an example if you want.

Is there a way to make it print nicely, like the old unordered dictionaries?

----------
components: Library (Lib)
messages: 122963
nosy: mikez302
priority: normal
severity: normal
status: open
title: pprint module doesn't work well with OrderedDicts
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  1 01:54:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Dec 2010 00:54:53 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1291164893.52.0.797026286008.issue1649329@psf.upfronthosting.co.za>


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

Congratulations.  Take the time you?ll need, if this doesn?t go into 3.2 it?ll just be in 3.3.

----------

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

From report at bugs.python.org  Wed Dec  1 01:57:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Dec 2010 00:57:02 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1291165022.0.0.995548748738.issue10592@psf.upfronthosting.co.za>


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

I?m afraid there is no way, but a robust solution will be designed.  See #7434.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> general pprint rewrite

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

From report at bugs.python.org  Wed Dec  1 01:58:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Dec 2010 00:58:39 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1291165119.17.0.866061912509.issue10535@psf.upfronthosting.co.za>


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

Committed in r86908. I'll leave this open because there still a few things (proposed in the previous message) that can be changed/improved.

----------

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

From report at bugs.python.org  Wed Dec  1 02:02:00 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 01:02:00 +0000
Subject: [issue10593] LRU Cache with maxsize=None
In-Reply-To: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za>
Message-ID: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za>


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

Nick, I may have found a straight-forward way to incorporate your idea for the cache to support maxsize=None.  Let me know what you think.

----------
assignee: ncoghlan
components: Library (Lib)
files: cache.diff
keywords: patch
messages: 122967
nosy: ncoghlan, rhettinger
priority: low
severity: normal
status: open
title: LRU Cache with maxsize=None
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19886/cache.diff

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

From report at bugs.python.org  Wed Dec  1 02:07:46 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 01:07:46 +0000
Subject: [issue10593] LRU Cache with maxsize=None
In-Reply-To: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za>
Message-ID: <1291165666.06.0.249484122498.issue10593@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file19887/cache2.diff

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

From report at bugs.python.org  Wed Dec  1 02:07:51 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 01:07:51 +0000
Subject: [issue10593] LRU Cache with maxsize=None
In-Reply-To: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za>
Message-ID: <1291165671.71.0.0563112895195.issue10593@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19886/cache.diff

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

From report at bugs.python.org  Wed Dec  1 02:13:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 01:13:20 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1291166000.38.0.717505867775.issue7434@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a rough concept of how to make the existing pprint module extendible without doing a total rewrite.  The actual handler is currently bogus (no thought out), so focus on the @guard decorator and the technique for scanning for handlers.

----------
Added file: http://bugs.python.org/file19888/rdh_pprint.py

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

From report at bugs.python.org  Wed Dec  1 02:36:00 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 01 Dec 2010 01:36:00 +0000
Subject: [issue10593] LRU Cache with maxsize=None
In-Reply-To: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za>
Message-ID: <1291167360.6.0.499812041068.issue10593@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Nice!

You may still need to use the lock even for the simple unbounded case though - incrementing hits and misses isn't atomic, so the statistics may be miscounted if you get a hit or miss in different threads at the same time.

Alternatively, we could just document the hit/miss statistics as approximate figures for tuning purposes rather than guaranteeing 100% accuracy in all situations.

----------

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

From report at bugs.python.org  Wed Dec  1 02:59:58 2010
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 01 Dec 2010 01:59:58 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291168798.38.0.857792504711.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

So, reading all your comments, I gather that my proposed patch for client.py which is

  try:
      self.sock.sendall(data)
  except TypeError:
      if isinstance(data, collections.Iterable):
          for d in t:
              self.sock.sendall(d)
      else:
          raise TypeError("data should be a bytes-like object or an iterable, got %r" % type(it))

is ok, because it avoids using hasattr to test for Iterable and avoids isinstance() to check for specific types (str, bytes...) but instead uses exceptions (as pitrou suggested)?

if that is ok with everyone, I just need to work more on request.py to remove the hasattr; I'll probably use the memoryview solution suggested by pitrou.

just to confirm: we WANT array.array("I", [1,2,3]) to have a content-length of 12, right?

----------

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

From report at bugs.python.org  Wed Dec  1 03:35:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Dec 2010 02:35:39 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1291170939.96.0.479774078821.issue10273@psf.upfronthosting.co.za>


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

s/regexp/regex/ done in r86910.

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

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

From report at bugs.python.org  Wed Dec  1 03:47:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 02:47:15 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1291171635.53.0.743627090318.issue6594@psf.upfronthosting.co.za>


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

Raymond, I'll follow up in private with Shawn. All the recent performance improvements done on JSON (in 3.2) mean the issue can be closed IMO.

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

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

From report at bugs.python.org  Wed Dec  1 04:09:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 03:09:56 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291172996.96.0.892230666091.issue3243@psf.upfronthosting.co.za>


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

> just to confirm: we WANT array.array("I", [1,2,3]) to have a content-
> length of 12, right?

Yes, since it will emit 12 bytes in the body (you could actually have a test for it).

----------

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

From report at bugs.python.org  Wed Dec  1 04:31:22 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Dec 2010 03:31:22 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/list.html#PyList_New
> Note: If length is greater than zero, ...

s/length/len/

----------
assignee: docs at python
components: Documentation
messages: 122974
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Typo in PyList_New doc.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Dec  1 04:34:15 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Dec 2010 03:34:15 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291174455.83.0.52849060852.issue10594@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

http://docs.python.org/c-api/list.html#PyList_GetItem
> Return the object at position pos in the list pointed to by p
s/p/list/

----------

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

From report at bugs.python.org  Wed Dec  1 04:35:02 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Dec 2010 03:35:02 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291174502.22.0.50316378101.issue10594@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

http://docs.python.org/c-api/list.html#PyList_GetItem
> Return the object at position pos in the list pointed to by p
s/pos/index/

----------

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

From report at bugs.python.org  Wed Dec  1 04:40:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 01 Dec 2010 03:40:05 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291174805.4.0.525217689869.issue10594@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/issue10594>
_______________________________________

From report at bugs.python.org  Wed Dec  1 04:46:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 03:46:17 +0000
Subject: [issue10593] LRU Cache with maxsize=None
In-Reply-To: <1291165319.63.0.0975088318832.issue10593@psf.upfronthosting.co.za>
Message-ID: <1291175177.16.0.155017850877.issue10593@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r86911.

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

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

From report at bugs.python.org  Wed Dec  1 04:46:59 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 01 Dec 2010 03:46:59 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291175219.15.0.822746350494.issue10594@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Thanks for the report,

Attaching a patch for Doc/c-api/list.rst in Python 3.2
If this is OK, I can backport the patch to other versions as well.

----------
keywords: +patch
nosy: +eli.bendersky
Added file: http://bugs.python.org/file19889/issue10594.py32.1.patch

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

From report at bugs.python.org  Wed Dec  1 04:52:23 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 01 Dec 2010 03:52:23 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1291175543.51.0.226628514354.issue5088@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I fuzzily recall there was somewhere a decision to use the American spelling of some words, like s/behaviour/behavior/ appearing in this patch. Is this right, or was it decided that it doesn't matter?

----------
nosy: +eli.bendersky
status: pending -> open

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

From report at bugs.python.org  Wed Dec  1 04:55:02 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 01 Dec 2010 03:55:02 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1291175702.37.0.647165770569.issue5088@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, also re your previous message, I personally would prefer seeing "contrary to what one can think" removed altogether. IMHO it's too chatty for an official document and doesn't really add new information over the sentence it follows.

----------

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

From report at bugs.python.org  Wed Dec  1 05:21:49 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Dec 2010 04:21:49 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291175219.15.0.822746350494.issue10594@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=SWOu=m+hDw321+cV=Fr0v+ZAgvFMH7yX3ck6c@mail.gmail.com>


INADA Naoki <songofacandy at gmail.com> added the comment:

OK, please.

On Wed, Dec 1, 2010 at 12:46 PM, Eli Bendersky <report at bugs.python.org> wrote:
>
> Eli Bendersky <eliben at gmail.com> added the comment:
>
> Thanks for the report,
>
> Attaching a patch for Doc/c-api/list.rst in Python 3.2
> If this is OK, I can backport the patch to other versions as well.
>
> ----------
> keywords: +patch
> nosy: +eli.bendersky
> Added file: http://bugs.python.org/file19889/issue10594.py32.1.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10594>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Dec  1 05:26:54 2010
From: report at bugs.python.org (Elias Zamaria)
Date: Wed, 01 Dec 2010 04:26:54 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1291177614.49.0.567825918975.issue10592@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

I forgot to mention, someone came up with this suggestion (http://stackoverflow.com/questions/4301069/any-way-to-properly-pretty-print-ordered-dictionaries-in-python/4303996#4303996). It is not the best, but the output is better than how it is now. Can it be somehow integrated into the PrettyPrinter.format method?

----------
resolution: duplicate -> 
status: closed -> open

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

From report at bugs.python.org  Wed Dec  1 06:19:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 05:19:29 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1291180769.47.0.554151038443.issue10592@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll discuss with Benjamin.  This could be construed as a simple bug fix.  The code is already in Py3.1.

Line 155:
- items = _sorted(object.items())
+ items = (list if issubclass(typ, OrderedDict) else _sorted)(object.items())

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson, rhettinger
stage: committed/rejected -> 

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

From report at bugs.python.org  Wed Dec  1 06:25:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 05:25:05 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291181105.53.0.130275783129.issue10594@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is fine.  Go ahead and backport if you feel so inclined.

----------
assignee: docs at python -> eli.bendersky
nosy: +rhettinger
priority: normal -> low
resolution:  -> accepted
versions:  -Python 2.6

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

From report at bugs.python.org  Wed Dec  1 06:33:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 05:33:21 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1291181601.07.0.289905826505.issue5088@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Note, the :attr:`~Option.dest` variable is a list which includes default
values if any are defined.  Options on the command-line are appended to
this list.  Accordingly, the list may contain both the default value and
the value passed on the command-line.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Dec  1 09:34:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Dec 2010 08:34:26 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1291192466.64.0.854902385792.issue10592@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder: general pprint rewrite -> 

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

From report at bugs.python.org  Wed Dec  1 10:41:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 01 Dec 2010 09:41:59 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291196519.64.0.486172629078.issue3243@psf.upfronthosting.co.za>


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

Give a try to this minor variation of the patch with tests added and let me know your review comments.

----------
Added file: http://bugs.python.org/file19890/Issue3243-4.patch

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

From report at bugs.python.org  Wed Dec  1 10:55:55 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 01 Dec 2010 09:55:55 +0000
Subject: [issue10084] SSL support for asyncore
In-Reply-To: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>
Message-ID: <1291197355.9.0.699580835559.issue10084@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


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

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

From report at bugs.python.org  Wed Dec  1 11:06:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 10:06:25 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291197985.58.0.52800759882.issue3243@psf.upfronthosting.co.za>


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

Senthil:

+        try:
+           self.sock.sendall(data)

Indentation problem here.

+                if isinstance(data,str):
+                    content_length = len(data)

I'm not sure I understand. What does sending an unicode string mean?

+        # Check iterable body support
+        def iterable_body():
+            yield "one"
+            yield "two"
+            yield "three"

Iterables of strings? this doesn't seem supported in the patch.

Also, it would be nice if the tests checked that the sent data is as expected.

----------

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

From report at bugs.python.org  Wed Dec  1 11:08:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 10:08:08 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291198088.61.0.672642147517.issue10594@psf.upfronthosting.co.za>


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

You don't need to backport, we'll do it ourselves. Can someone from the doc team please review/commit?

----------
assignee: eli.bendersky -> docs at python
nosy: +pitrou
stage:  -> patch review

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

From report at bugs.python.org  Wed Dec  1 11:37:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 10:37:10 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1291199830.09.0.828931643132.issue8805@psf.upfronthosting.co.za>


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

HTTPSHandler now allows to pass an SSLContext and the old API should be buried in the ground, closing.

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

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

From report at bugs.python.org  Wed Dec  1 12:32:41 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 01 Dec 2010 11:32:41 +0000
Subject: [issue10595] Adding a syslog.conf reader in syslog
In-Reply-To: <1291203161.89.0.870759954789.issue10595@psf.upfronthosting.co.za>
Message-ID: <1291203161.89.0.870759954789.issue10595@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

The syslog module allows to configure via openlog() the facility.

There's one missing feature though, I'd love to have in a new API: a way to read the syslog configuration, and in particular to know where each facility file is located on the system.

e.g.:

  >>> from syslog import get_config, LOG_AUTH
  >>> get_config(LOG_AUTH)
  {'filename': '/var/log/auth.log', some other stuff}

I am not sure how easy it would be, looking at the syslog C API...

----------
components: Library (Lib)
messages: 122990
nosy: jafo, tarek
priority: normal
severity: normal
status: open
title: Adding a syslog.conf reader in syslog
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec  1 12:53:19 2010
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCl0LvRg9GC0YfQuNC9?=)
Date: Wed, 01 Dec 2010 11:53:19 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>


New submission from ?????? ??????? <sercxjo at gmail.com>:

Result of the modulo operator is wrong:

>>> (-2.22044604925e-16)%4
4.0
>>> (-4.0)%4
-0.0

----------
messages: 122991
nosy: Sergio.?lut?in
priority: normal
severity: normal
status: open
title: modulo operator bug
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec  1 13:06:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 12:06:57 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291205217.51.0.179014265974.issue10596@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  1 13:24:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 01 Dec 2010 12:24:29 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291206269.55.0.960032871611.issue10596@psf.upfronthosting.co.za>


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

What results were you expecting here?  Both those results look fine to me (though it's arguable that the second should be +0.0 rather than -0.0).

----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Wed Dec  1 14:10:05 2010
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCl0LvRg9GC0YfQuNC9?=)
Date: Wed, 01 Dec 2010 13:10:05 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291209005.58.0.953899586785.issue10596@psf.upfronthosting.co.za>


?????? ??????? <sercxjo at gmail.com> added the comment:

>From the documetation:
The modulo operator always yields a result with the same sign as its second operand (or zero); the absolute value of the result is strictly smaller than the absolute value of the second operand.

----------

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

From report at bugs.python.org  Wed Dec  1 14:40:44 2010
From: report at bugs.python.org (Ole Laursen)
Date: Wed, 01 Dec 2010 13:40:44 +0000
Subject: [issue7359] mailbox cannot modify mailboxes in system mail spool
In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
Message-ID: <1291210844.69.0.948602362952.issue7359@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

Just got bitten by this too.

Renaming is good and all, but as far as I can tell, it will never work with the system spool. It's not just that you can't create a temporary file in the directory, you can't rename files into it either. If I create an empty file somewhere and try to rename it to overwrite my mailbox, I get a permission denied. Sad. :(

So I think you have to bite the bullet and write directly to the file. Either that or define that the module can't be used to work with system spool mailboxes, at least on Debian. But that would be even more sad.

----------
nosy: +olau

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

From report at bugs.python.org  Wed Dec  1 15:40:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 01 Dec 2010 14:40:09 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291214409.42.0.971615818964.issue10596@psf.upfronthosting.co.za>


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

Did you look at the second footnote on that page?

----------

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

From report at bugs.python.org  Wed Dec  1 15:56:56 2010
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 01 Dec 2010 14:56:56 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291215416.28.0.0920358124785.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

orsenthil: Hi, i don't quite understand why iter() needs to be called explicitly on data? As I understand it, if data is an iterable then you can use a for loop on it directly.

----------

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

From report at bugs.python.org  Wed Dec  1 16:36:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 01 Dec 2010 15:36:50 +0000
Subject: [issue10594] Typo in PyList_New doc.
In-Reply-To: <1291174282.03.0.355387197898.issue10594@psf.upfronthosting.co.za>
Message-ID: <1291217810.54.0.210843264743.issue10594@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r86914.

----------
nosy: +georg.brandl
resolution: accepted -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Dec  1 16:49:53 2010
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 01 Dec 2010 15:49:53 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291218593.66.0.217611113.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

attaching new patch. this implements the memoryview solution suggested by pitrou. but it does contain this thing:

if not request.has_header('Content-length'):
    if (not hasattr(data, '__read__') and 
        isinstance(data, collections.Iterable)):
        print(data,"is an iterable")
        try:
            m = memoryview(data)
            print(m.itemsize * len(m))
            request.add_unredirected_header(
                'Content-length', '%d' % (len(m) * m.itemsize))
        except TypeError:
            try:
                request.add_unredirected_header(
                    'Content-length', '%d' % len(data))
            except TypeError:
                raise ValueError(
                    "No Content-Length specified for iterable body")

why is it so nested? because data can support 3 different interfaces:

1) Buffer interface, in that case use memoryview to count bytes
2) Can call len but not buffer: assume len == #bytes
3) Iterable but cannot call len or memoryview: raise ValueError

I hope there is a simpler way...

----------
Added file: http://bugs.python.org/file19891/issue_3243_py3k_5.patch

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

From report at bugs.python.org  Wed Dec  1 16:50:30 2010
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 01 Dec 2010 15:50:30 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291218630.37.0.938665794504.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

attaching new patch. this implements the memoryview solution suggested by pitrou. but it does contain this thing:

if not request.has_header('Content-length'):
    if (not hasattr(data, '__read__') and 
        isinstance(data, collections.Iterable)):
        print(data,"is an iterable")
        try:
            m = memoryview(data)
            print(m.itemsize * len(m))
            request.add_unredirected_header(
                'Content-length', '%d' % (len(m) * m.itemsize))
        except TypeError:
            try:
                request.add_unredirected_header(
                    'Content-length', '%d' % len(data))
            except TypeError:
                raise ValueError(
                    "No Content-Length specified for iterable body")

why is it so nested? because data can support 3 different interfaces:

1) Buffer interface, in that case use memoryview to count bytes
2) Can call len but not buffer: assume len == #bytes
3) Iterable but cannot call len or memoryview: raise ValueError

I hope there is a simpler way...

----------
Added file: http://bugs.python.org/file19892/issue_3243_py3k_5.patch

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

From report at bugs.python.org  Wed Dec  1 16:51:20 2010
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 01 Dec 2010 15:51:20 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291218680.65.0.437984673116.issue3243@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


Removed file: http://bugs.python.org/file19892/issue_3243_py3k_5.patch

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

From report at bugs.python.org  Wed Dec  1 17:07:31 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Dec 2010 16:07:31 +0000
Subject: [issue10597] Py_SetPythonHome document shows same url twice.
In-Reply-To: <1291219651.16.0.0325545268519.issue10597@psf.upfronthosting.co.za>
Message-ID: <1291219651.16.0.0325545268519.issue10597@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/init.html#Py_SetPythonHome
> The libraries are searched in home/lib/pythonversion and home/lib/pythonversion.

Is the second "{home}/lib/python{version}" wrong?

----------
assignee: docs at python
components: Documentation
messages: 123000
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Py_SetPythonHome document shows same url twice.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Dec  1 18:01:32 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 01 Dec 2010 17:01:32 +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: <1291222892.6.0.659354622139.issue8743@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Wed Dec  1 18:02:09 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 01 Dec 2010 17:02:09 +0000
Subject: [issue10589] I/O ABC docs should specify which methods have
	implementations
In-Reply-To: <1291143953.85.0.0204032538698.issue10589@psf.upfronthosting.co.za>
Message-ID: <1291222929.51.0.00985923078643.issue10589@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Wed Dec  1 18:08:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Dec 2010 17:08:26 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291218630.37.0.938665794504.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291223302.3569.3.camel@localhost.localdomain>


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

> if not request.has_header('Content-length'):
>     if (not hasattr(data, '__read__') and 

What is __read__ supposed to be?

> 2) Can call len but not buffer: assume len == #bytes

Why do you need it at all?

----------

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

From report at bugs.python.org  Wed Dec  1 19:32:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:32:22 +0000
Subject: [issue887237] Machine integers
Message-ID: <1291228342.57.0.672880333255.issue887237@psf.upfronthosting.co.za>


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

As far as I understand, the main concern about issue887237.diff was code duplication.  There are two ways to fight it: C preprocessor tricks as in issue887237-macro.diff and code generation as done in numpy.  With improved macro support in many compilers and debuggers, preprocessor approach may be preferable.  However I cannot move this issue forward until those who objected to code duplication review the latest patch.  Unassigning.

----------
assignee: belopolsky -> 
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Wed Dec  1 19:35:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:35:59 +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: <1291228559.07.0.155681527889.issue5516@psf.upfronthosting.co.za>


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


----------
resolution:  -> postponed
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Wed Dec  1 19:40:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:40:45 +0000
Subject: [issue9268] Document annotation option to pickletools.dis
In-Reply-To: <1279222638.31.0.459529413565.issue9268@psf.upfronthosting.co.za>
Message-ID: <1291228845.33.0.571966410814.issue9268@psf.upfronthosting.co.za>


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


----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
title: Add annotation option to pickletools.dis -> Document annotation option to pickletools.dis

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

From report at bugs.python.org  Wed Dec  1 19:43:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:43:28 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1291229008.41.0.993889865615.issue9528@psf.upfronthosting.co.za>


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

BDFL and python-dev were opposed to this idea.

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

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

From report at bugs.python.org  Wed Dec  1 19:46:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:46:13 +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: <1291229173.03.0.398152716624.issue5476@psf.upfronthosting.co.za>


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

Travis, feel free to close this without further action or use the information here to open a numpy issue.

----------
assignee: belopolsky -> teoliphant
status: open -> pending

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

From report at bugs.python.org  Wed Dec  1 19:46:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:46:55 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1291229215.25.0.157276411262.issue8902@psf.upfronthosting.co.za>


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


----------
resolution:  -> postponed
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Wed Dec  1 19:47:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:47:29 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1291229249.96.0.401866412801.issue766910@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18959/unnamed

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

From report at bugs.python.org  Wed Dec  1 19:47:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:47:36 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1291229256.39.0.0289425358016.issue766910@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18960/unnamed

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

From report at bugs.python.org  Wed Dec  1 19:51:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 18:51:06 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1291229466.38.0.404350496056.issue766910@psf.upfronthosting.co.za>


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

Eli,

Would you like to review this patch?

----------
nosy: +eli.bendersky -BreamoreBoy

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

From report at bugs.python.org  Wed Dec  1 19:56:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Dec 2010 18:56:13 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1291229773.37.0.559392401183.issue9527@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Wed Dec  1 20:01:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Dec 2010 19:01:00 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1291230060.04.0.745616664008.issue7662@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Dec  1 21:07:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 20:07:26 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1291234046.23.0.834068923316.issue4113@psf.upfronthosting.co.za>


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

I simplified the partial_repr() code in issue4113b.diff and committed as r86916.

I wonder, however, if for the common case of func being a named function, displaying func.__name__ or func.__module__ + '.' + func.__name__ in repr(partial) may be more apropriate than repr(f).

For example, 

functools.partial(f, 1, 2, 3, a=5, b={}, c='7')

instead of

functools.partial(<function f at 0x100592d98>, 1, 2, 3, a=5, b={}, c='7')

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Wed Dec  1 21:12:59 2010
From: report at bugs.python.org (River Tarnell)
Date: Wed, 01 Dec 2010 20:12:59 +0000
Subject: [issue10598] curses fails to import on Solaris
In-Reply-To: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za>
Message-ID: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za>


New submission from River Tarnell <river at tamara.tcx.org.uk>:

On Solaris 10 using system libcurses, curses fails to import:

hemlock% python3.1
Python 3.1.3 (r313:86834, Dec  1 2010, 19:51:26) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
Traceback (most recent call last):
  File "/opt/ts/python/3.1/lib/python3.1/curses/__init__.py", line 57, in <module>
    has_key
NameError: name 'has_key' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/ts/python/3.1/lib/python3.1/curses/__init__.py", line 59, in <module>
    from has_key import has_key
ImportError: No module named has_key
>>>

----------
components: Extension Modules
messages: 123007
nosy: rtarnell
priority: normal
severity: normal
status: open
title: curses fails to import on Solaris
versions: Python 3.1

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

From report at bugs.python.org  Wed Dec  1 21:21:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Dec 2010 20:21:43 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291234903.41.0.433013647756.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Antoine and Raymond, thank you for the valuable feedback.

Attached is a revised version of the patch, which restricts changes to those directly related to moving elements in the keys and values arrays at the same time.  I apologize for having gotten a little carried away with optimizing.

I think I eliminated all of the significant style differences as well.  If you still see glaring style mismatches, please let me know.  It's possible that the differences aren't visible to my eyes. ;-)

http://codereview.appspot.com/3369042/diff/1/Objects/listobject.c

Please let me know what you think of the revised version.

----------
Added file: http://bugs.python.org/file19893/sort-faster-3.patch

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

From report at bugs.python.org  Wed Dec  1 21:28:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Dec 2010 20:28:39 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1291235319.8.0.259560317672.issue4113@psf.upfronthosting.co.za>


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

I would prefer the module.name without the repr decoration.

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

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

From report at bugs.python.org  Wed Dec  1 21:34:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Dec 2010 20:34:00 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1291235640.85.0.495937081756.issue4113@psf.upfronthosting.co.za>


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

I think the main purpose of repr is debugging, so I?d favor the unambiguous form (with the id) to the nice-looking one (module.name).

----------

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

From report at bugs.python.org  Wed Dec  1 21:36:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 20:36:44 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1291235804.22.0.794025613271.issue4113@psf.upfronthosting.co.za>


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

Let me close this issue before any serious bikeshedding begins.  We can always reconsider when users complain that eval(repr(x)) does not work for their partial objects.

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

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

From report at bugs.python.org  Wed Dec  1 21:52:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 20:52:37 +0000
Subject: [issue1598083] Top-level exception handler writes to stdout unsafely
Message-ID: <1291236757.99.0.0435445612305.issue1598083@psf.upfronthosting.co.za>


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

I don't see anything "easy" in this issue.  Error handling in exception or signal handlers is quite tricky.

I don't see this as a high priority either, but will leave this for others to decide.

----------
keywords:  -easy
nosy: +belopolsky

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

From report at bugs.python.org  Wed Dec  1 22:02:36 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Dec 2010 21:02:36 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291237356.37.0.306561476597.issue10092@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19306/unnamed

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

From report at bugs.python.org  Wed Dec  1 22:02:41 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Dec 2010 21:02:41 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291237361.37.0.786544359193.issue10092@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19316/unnamed

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

From report at bugs.python.org  Wed Dec  1 22:07:06 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Dec 2010 21:07:06 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291237626.0.0.547300412084.issue10092@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)
is not valid because 'fr_FR' is not a valid value for the 'locale' argument

What is valid is this:
>>> calendar.LocaleTextCalendar(locale='French').formatmonthname(2010,10,10)

----------

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

From report at bugs.python.org  Wed Dec  1 22:16:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 21:16:11 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291238171.85.0.949289838058.issue10092@psf.upfronthosting.co.za>


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

Bo?tjan,

Please don't add comments to closed issues.  If you believe there is a remaining issue, please file a new report.  Issue numbers are in good supply!

This issue was fixed in r85728.  It is best when this information is the last message on a closed issue.

----------

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

From report at bugs.python.org  Wed Dec  1 22:21:41 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Dec 2010 21:21:41 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1291238171.85.0.949289838058.issue10092@psf.upfronthosting.co.za>
Message-ID: <AANLkTin+Fn=D1bDvcRJ_w+FOBT26CU9OvxJx7s7vpEOQ@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Yes, I know this issue is closed but I wonder how could your Python
interpreter not error on
>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)

Please retry executing the above line of code in Python 2.7.1 interpreter
and tell me if you get an error. I get this:
>>> import calendar
>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\calendar.py", line 522, in formatmonthname
    with TimeEncoding(self.locale) as encoding:
  File "C:\Python27\lib\calendar.py", line 490, in __enter__
    _locale.setlocale(_locale.LC_TIME, self.locale)
  File "C:\Python27\lib\locale.py", line 531, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

----------
Added file: http://bugs.python.org/file19894/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________
-------------- next part --------------
Yes, I know this issue is closed but I wonder how could your Python interpreter not error on<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; color: rgb(80, 0, 80); ">&gt;&gt;&gt; calendar.LocaleTextCalendar(locale=&#39;fr_FR&#39;).formatmonthname(2010,10,10)</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; color: rgb(80, 0, 80); "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; color: rgb(80, 0, 80); ">Please retry executing the above line of code in Python 2.7.1 interpreter and tell me if you get an error. I get this:</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; color: rgb(80, 0, 80); "><div>&gt;&gt;&gt; import calendar</div><div>&gt;&gt;&gt; calendar.LocaleTextCalendar(locale=&#39;fr_FR&#39;).formatmonthname(2010,10,10)</div>
<div>Traceback (most recent call last):</div><div>????File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;</div><div>????File &quot;C:\Python27\lib\calendar.py&quot;, line 522, in formatmonthname</div><div>???? ??with TimeEncoding(self.locale) as encoding:</div>
<div>????File &quot;C:\Python27\lib\calendar.py&quot;, line 490, in __enter__</div><div>???? ??_locale.setlocale(_locale.LC_TIME, self.locale)</div><div>????File &quot;C:\Python27\lib\locale.py&quot;, line 531, in setlocale</div>
<div>???? ??return _setlocale(category, locale)</div><div>locale.Error: unsupported locale setting</div></span></div>

From report at bugs.python.org  Wed Dec  1 22:21:49 2010
From: report at bugs.python.org (Michael Brooks)
Date: Wed, 01 Dec 2010 21:21:49 +0000
Subject: [issue10599] sgmllib.parse_endtag() is not respecting quoted text
In-Reply-To: <1291238509.2.0.989759336682.issue10599@psf.upfronthosting.co.za>
Message-ID: <1291238509.2.0.989759336682.issue10599@psf.upfronthosting.co.za>


New submission from Michael Brooks <firealwaysworks at gmail.com>:

In the attached example is a very simple usage of sgmllib that is trying to parse:
<input value="><a href=http://bug>link</a>">

The bug is that sgmllib is parsing this href.  Browsers on the other hand see this as the input's value.  

Also keep in mind that escaping of quote marks in HTML is not like python.  \" is not a character literal "  thus <input value="\"><a href=http://bug>link</a>"> is still quoted text and the href should not be parsed. 

Thank you

----------
components: None
files: sgmllib_bug.py
messages: 123016
nosy: Michael.Brooks
priority: normal
severity: normal
status: open
title: sgmllib.parse_endtag() is not respecting quoted text
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19895/sgmllib_bug.py

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

From report at bugs.python.org  Wed Dec  1 22:27:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 01 Dec 2010 21:27:50 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291238870.17.0.414915497459.issue10092@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/issue10092>
_______________________________________

From report at bugs.python.org  Wed Dec  1 22:34:31 2010
From: report at bugs.python.org (Michael Brooks)
Date: Wed, 01 Dec 2010 21:34:31 +0000
Subject: [issue10599] sgmllib.parse_endtag() is not respecting quoted text
In-Reply-To: <1291238509.2.0.989759336682.issue10599@psf.upfronthosting.co.za>
Message-ID: <1291239271.3.0.324608177949.issue10599@psf.upfronthosting.co.za>


Michael Brooks <firealwaysworks at gmail.com> added the comment:

Oops, I had a misnomer in my bug report. 
<input value="\"><a href=http://bug>link</a>"> is not escaped and there for the href should be parsed in this condition but not parsed in the attached sgmllib_bug.py.

----------

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

From report at bugs.python.org  Wed Dec  1 22:39:53 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Wed, 01 Dec 2010 21:39:53 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291239593.32.0.190466921922.issue10092@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

On windows, "France" may work and "fr_FR" may not; yet on OSX its exactly the opposite. Its not consistant across platforms.

----------

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

From report at bugs.python.org  Wed Dec  1 22:44:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 01 Dec 2010 21:44:04 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1291239844.35.0.516563960548.issue10092@psf.upfronthosting.co.za>


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

Bo?tjan, please see issue 10466 for further information about your question on fr_FR vs French.  Windows, as usual, does not follow the standards.

----------

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

From report at bugs.python.org  Thu Dec  2 00:14:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Dec 2010 23:14:05 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1291245245.61.0.0637777009543.issue6135@psf.upfronthosting.co.za>


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

About the topic:
> subprocess seems to use local 8-bit encoding and gives no choice
I don't understand that: by default, Python 2 and Python 3 use byte strings, so there is no encoding (nor error handler).

I don't see how you can get unicode from a process only using subprocess. But with Python 3, you can get unicode if you set universal_newlines option to True.

So for Python 2, it's a new feature (get unicode), and for Python 3, it's a new option to specify the encoding. The title should be changed to something like "subprocess: add an option to specify stdin, stdout and/or stderr encoding and errors" and the type should be changed to "feature request".

Or am I completly wrong?

----------

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

From report at bugs.python.org  Thu Dec  2 00:16:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Dec 2010 23:16:45 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291245405.23.0.223483860341.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks.  This nice, clean diff is much more reviewable and it looks like what I expected.   

The use of  Py_LOCAL_INLINE is new to me since we usually use #define instead, but this has a cleaner look to it.  I am unclear on whether all the our target compilers support an inline keyword.   If you're sure it works everywhere, that's great.  If not, consider going back to ugly defines -- those reliably work everywhere.

Also note that this patch puts a lot of faith in branch prediction.  If some target processor doesn't support it, or has limited ability to remember predictions, or mispredicts, then the code will be slower.

That being said, I'm happy with the patch.   You have a +1 from me.

----------

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

From report at bugs.python.org  Thu Dec  2 00:24:56 2010
From: report at bugs.python.org (Campbell Barton)
Date: Wed, 01 Dec 2010 23:24:56 +0000
Subject: [issue10600] surrogateescape'd paths not readable on Windows XP.
In-Reply-To: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za>
Message-ID: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

Attached is a script which works in linux but not windows XP 32bit with Python 3.1.3.

The problem is that the path can be written to when specified as bytes but when escaped it fails.

----------
components: IO
files: utf8_surrogateescape.py
messages: 123022
nosy: ideasman42
priority: normal
severity: normal
status: open
title: surrogateescape'd paths not readable on Windows XP.
versions: Python 3.1
Added file: http://bugs.python.org/file19896/utf8_surrogateescape.py

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

From report at bugs.python.org  Thu Dec  2 00:27:45 2010
From: report at bugs.python.org (Campbell Barton)
Date: Wed, 01 Dec 2010 23:27:45 +0000
Subject: [issue10600] surrogateescape'd paths not readable on Windows XP.
In-Reply-To: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za>
Message-ID: <1291246065.68.0.685341372856.issue10600@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

note, this bug was reported to me by a user running windows 7, 64bits.

----------

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

From report at bugs.python.org  Thu Dec  2 00:40:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Dec 2010 23:40:26 +0000
Subject: [issue6135] subprocess seems to use local 8-bit encoding and gives no
	choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1291246826.17.0.484484110686.issue6135@psf.upfronthosting.co.za>


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

> ... it always seems to use the local 8-bit encoding

The locale encoding is not necessary a 8-bit encoding, it can by a multibyte like... UTF-8 :-)

--

subprocess.patch: You should maybe use io.open(process.stdout.fileno(), encoding=..., errors=...) instead of codecs.getreader/getwriter. The code will be closer to Python 3. I think that the io module has a better support of unicode than codec reader/writer objects and a nicer API. See:
http://bugs.python.org/issue8796#msg106339

--

> ... allowing [encoding and errors] to accept either a single string
> (as now), or a dict with keys 'stdin', 'stdout', 'stderr'

I like this idea. But what about other TextIOWrapper (or other file classes) options: buffer size, newline, line_buffering, etc.?

Why not using a dict for existing stdin, stdout and stderr arguments? Dummy example:

process = Popen(
   command,
   stdin={'file': PIPE, 'encoding': 'iso-8859-1', 'newline': False},
   stdout={'file': PIPE', 'encoding': 'utf-8', 'buffering': 0, 'line_buffering': False},
   ...)

If stdin, stdout or stderr is a dict: the default value of its 'file' key can be set to PIPE. I don't think that it's possible to choose the encoding, buffer size, or anything else if stdin, stdout or stderr is not a pipe.

With this solution, you cannot specify the encoding for stdin, stdout and stderr at once. You have at least to repeat the encoding for stdin and stdout (and use stderr=STDOUT).

--

I still hesitate to accept this feature request. Is it really needed to add extra arguments for TextIOWrapper? Can't the developer create its own TextIOWrapper object with all interesting options?

In Python 3, be able to specify stdout encoding is an interesting feature. Control the buffers size is also an interesting option.

My problem is maybe the usage of a dict to specify various options. I'm not sure that it is extensible to support future needs.

----------

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

From report at bugs.python.org  Thu Dec  2 00:42:12 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Dec 2010 23:42:12 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291246932.8.0.416263865072.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> The use of  Py_LOCAL_INLINE is new to me since we usually use #define
> instead, but this has a cleaner look to it.  I am unclear on whether
> all the our target compilers support an inline keyword.   If you're
> sure it works everywhere, that's great.

I fixed ./configure to properly set up Py_LOCAL_INLINE in Issue5553. :-)

It will expand to "static inline" under both MSVC and gcc.  On older compilers, it may expand to "static __inline__", "static __inline", or whatever else is needed to get the job done.  

As a last resort, it will expand to simply "static", but I don't know of any 32-bit (or 64-bit) compilers where that would actually happen.

> Also note that this patch puts a lot of faith in branch prediction.
> If some target processor doesn't support it, or has limited ability
> to remember predictions, or mispredicts, then the code will be slower.

I think even a limited amount of memory dedicated to branch prediction should be sufficient.  There are two cases:

1) Sorting a simple type, like an int: the comparison is lightweight, and the CPU should have plenty of memory to remember which branch to take in the sorting code.

2) Sorting a complex type (i.e., calling a __lt__ method written in Python): the processor might not be able to remember which branch to take, but the performance impact will be small (as a percentage) since most of the CPU is being consumed by the comparisons.

Thanks for taking the time to review this.

----------

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

From report at bugs.python.org  Thu Dec  2 01:18:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 00:18:00 +0000
Subject: [issue4335] inspect.getsourcelines ignores last line in module
In-Reply-To: <1226909351.26.0.938399226191.issue4335@psf.upfronthosting.co.za>
Message-ID: <1291249080.3.0.475069272859.issue4335@psf.upfronthosting.co.za>


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

3.2 and 2.7 don't exhibit this issue.  I added a test in r86922.

----------
nosy:  -BreamoreBoy
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 01:38:51 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Dec 2010 00:38:51 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291250331.44.0.20647116632.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Just for the record, I wanted to highlight how little room there is for optimization here.  The sort wrapper is *very* thin:

sortwrapper_richcompare(sortwrapperobject *a, sortwrapperobject *b, int op)
{
    if (!PyObject_TypeCheck(b, &PySortWrapper_Type)) {
        PyErr_SetString(PyExc_TypeError,
            "expected a sortwrapperobject");
        return NULL;
    }
    return PyObject_RichCompare(a->key, b->key, op);
}

When a key function is defined, this is all you can possibly shave off the time for a comparison.  When a key function is not defined, there was no overhead at all.

With the patch, we're relying on branch prediction to minimize the cost to the regular case and adding a little indirection in the form of lo variables becoming lo.keys, etc.  And the number of memmoves is doubled.

To me, the main advantage of the patch is that it saves a little memory for each key:

   typedef struct {
       PyObject_HEAD
       PyObject *key;
       PyObject *value;
   } sortwrapperobject;

Just wanted to post this so there weren't any illusions about the patch being a big win.

----------

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

From report at bugs.python.org  Thu Dec  2 02:06:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Dec 2010 01:06:19 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291251979.37.0.0915327850919.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> Just wanted to post this so there weren't any illusions about the
> patch being a big win.

> When a key function is defined, this is all you can possibly shave
> off the time for a comparison.

I don't want to argue whether the patch is a big win or not (I recognize that it is a tradeoff), but when using a key it does shave off more than the call to sortwrapper_richcompare.

Stack with sortwrapper:

long_richcompare
do_richcompare
PyObject_RichCompare
sortwrapper_richcompare
do_richcompare
PyObject_RichCompare
PyObject_RichCompareBool
count_run
list_sort

Stack without:

long_richcompare
do_richcompare
PyObject_RichCompare
PyObject_RichCompareBool
count_run
list_sort

----------

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

From report at bugs.python.org  Thu Dec  2 02:23:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 01:23:45 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291253025.45.0.0261977305694.issue10580@psf.upfronthosting.co.za>


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

I think Bo?tjan is correct that that sentence is not parallel to the others.  If I understand correctly, at that point the installation is complete, and it is the final 'exit or back' dialog.  So I think the title should be "Complete Python x.x.x Installation".  Note, however, that I'm just looking at the code, not running the install.  Brian has more experience with the typical installer dialogs, so he'll have a better opinion, I think.

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

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

From report at bugs.python.org  Thu Dec  2 02:31:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 01:31:51 +0000
Subject: [issue2380] Raise a Py3K warning for catching nested tuples with
	non-BaseException exceptions
In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za>
Message-ID: <1291253511.24.0.607855629963.issue2380@psf.upfronthosting.co.za>


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

issue2380.diff does not apply anymore.

----------
assignee:  -> belopolsky
stage:  -> needs patch

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

From report at bugs.python.org  Thu Dec  2 02:43:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 01:43:27 +0000
Subject: [issue10601] sys.displayhook: use backslashreplace error handler if
	repr(value) is not encodable to sys.stdout
In-Reply-To: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za>
Message-ID: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za>


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

On Windows, the Python interpreter fails to display a result if stdout encoding is unable to encode it. This problem exists since Python 3.0. Eg. see issue #1602.

This problem is not specific to Windows. Even if stdout encoding is UTF-8 (which is the default encoding of Mac OS X and most Linux distributions), it fails on surrogate characters (because the UTF-8 encoder refuses surrogate characters in Python 3). Eg. see issue #5110.

Even if a Python (core? :-)) developer can see this behaviour as expected, it looks like different users (including me) don't like it and would prefer to see the result instead of an unicode exception. The problem is that we don't know directly (except for simple commands) if the error comes from the command or if printing the result failed.

This issue is specific to sys.displayhook, the callback used by the Python interpreter to display the result of a command. It doesn't concern print() or sys.stdout.write().

--

The best solution would be to check if the terminal is able to render a character, but this is not possible for technical reasons. The best that we can do is to catch the UnicodeEncodeError and use another error handler (than sys.stdout.errors) which doesn't fail. 'backslashreplace' is a good candidate.

Ezio Melotti implemented this solution and attached a patch to issue #9198.

I wrote a new version of his patch, changes:

 - Create a subfunction (for better readability)
 - Clear the UnicodeEncodeError before calling sys_displayhook_unencodable() (anyway, the exception will be lost on next error, eg. if PyObject_GetAttrString() fails)
 - Clear the (AttributeError) exception if PyObject_GetAttrString(outf, "buffer") fails
 - Add an unit test: test ASCII, ISO-8859-1 and UTF-8 with non-ASCII, surrogate and non-BMP (printable or not) characters
 - Complete and update sys.displayhook documentation
 - Fix a refleak if stdout_encoding_str == NULL
 - Use PyObject_CallMethod() instead of PyTuple_Pack() + PyEval_CallObject() for a shorter (and more readable) code

--

I don't know how to test the case: sys.stdout.write(repr(value)) fails and sys.stdout has no buffer attribute. A mockup should maybe be used in the unit test?

----------
components: Unicode
files: displayhook_unencodable.patch
keywords: patch
messages: 123031
nosy: belopolsky, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: sys.displayhook: use backslashreplace error handler if repr(value) is not encodable to sys.stdout
versions: Python 3.2
Added file: http://bugs.python.org/file19897/displayhook_unencodable.patch

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

From report at bugs.python.org  Thu Dec  2 02:48:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 01:48:11 +0000
Subject: [issue10601] sys.displayhook: use backslashreplace error handler if
	repr(value) is not encodable to sys.stdout
In-Reply-To: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za>
Message-ID: <1291254491.47.0.673140916801.issue10601@psf.upfronthosting.co.za>


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

This issue is opposed to the PEP 3128:

<< Default error-handler of sys.stdout should be 'backslashreplace'.

Stuff written to stdout might be consumed by another program that might misinterpret the escapes. For interactive session, it is possible to make 'backslashreplace' error-handler to default, but may add confusion of the kind "it works in interactive mode but not when redirecting to a file". >>

But if you read #1602, #5110 and #9198, you will see that not everybody agrees with the PEP.

----------

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

From report at bugs.python.org  Thu Dec  2 02:49:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 01:49:09 +0000
Subject: [issue9198] Should repr() print unicode characters outside the BMP?
In-Reply-To: <1278579187.34.0.662391507791.issue9198@psf.upfronthosting.co.za>
Message-ID: <1291254549.71.0.769411100598.issue9198@psf.upfronthosting.co.za>


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

I created a new issue for Ezio's proposition to patch sys.displayhook: issue #10601.

To answer the initial question, "Should repr() print unicode characters outside the BMP?", Marc-Andre, Ezio and me agree that we should keep the current behavior for non-BMP chars (i.e. print them normally) and so I close this issue.

----------

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

From report at bugs.python.org  Thu Dec  2 02:49:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 01:49:27 +0000
Subject: [issue10601] sys.displayhook: use backslashreplace error handler if
	repr(value) is not encodable to sys.stdout
In-Reply-To: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za>
Message-ID: <1291254567.35.0.555684012689.issue10601@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc, lemburg

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

From report at bugs.python.org  Thu Dec  2 02:51:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 01:51:06 +0000
Subject: [issue9198] Should repr() print unicode characters outside the BMP?
In-Reply-To: <1278579187.34.0.662391507791.issue9198@psf.upfronthosting.co.za>
Message-ID: <1291254666.09.0.099322503816.issue9198@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  2 02:52:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 01:52:42 +0000
Subject: [issue10601] sys.displayhook: use backslashreplace error handler if
	repr(value) is not encodable to sys.stdout
In-Reply-To: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za>
Message-ID: <1291254762.91.0.651899574177.issue10601@psf.upfronthosting.co.za>


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

> This issue is opposed to the PEP 3128:
>
> << Default error-handler of sys.stdout should be 'backslashreplace'....

Oops sorry, no it is not opposed to the PEP (this issue doesn't propose to change the default error handler of sys.stdout).

----------

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

From report at bugs.python.org  Thu Dec  2 03:03:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 02:03:07 +0000
Subject: [issue10600] surrogateescape'd paths not readable on Windows XP.
In-Reply-To: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za>
Message-ID: <1291255387.65.0.528755246358.issue10600@psf.upfronthosting.co.za>


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

Use surrogateescape error handler to decode a Windows path is not a good idea. On Windows, the problem is not to decode a path (ANSI => wide char), but to encode a path (wide char => ANSI) to use a function expecting bytes path encoded to the ANSI code page. surrogateescape is only useful on the *decode* operation, to store undecodable bytes in special characters.

Why do you decode a Windows path using UTF-8? UTF-8 is not used, by default, as an ANSI code page. But first, what do you manipulate bytes path on Windows?

If you would like a portable program supporting UNIX/BSD (bytes) and Windows (unicode) paths with a single type, you should use str instead of bytes, because Unicode (with surrogateescape) is a superset of bytes.

Python 3.2 has os.fsencode() and os.fsdecode() functions to do that easily (to decode/encode UNIX/BSD paths).

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Dec  2 03:10:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 02:10:30 +0000
Subject: [issue10417] unittest triggers UnicodeEncodeError with non-ASCII
	character in the docstring of the test function
In-Reply-To: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za>
Message-ID: <1291255830.72.0.859684355687.issue10417@psf.upfronthosting.co.za>


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

See also #10601: "sys.displayhook: use backslashreplace error handler if repr(value) is not encodable to sys.stdout".

----------

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

From report at bugs.python.org  Thu Dec  2 03:15:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 02:15:11 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1291256111.87.0.822966202972.issue8863@psf.upfronthosting.co.za>


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

> If it's an env variable, though, it should be clear that it's
> CPython-specific, so I'm not sure how to call it.

Why do you think that only this variable is CPython-specific? CPython has an option called PYTHONDONTWRITEBYTECODE, but PyPy doesn't create .pyc files (and I suppose that nor IronPython nor Jython create such files).

I propose to call the variable PYTHONNOFAULTHANDLER. I removed "SEG" because it does catch other faults than segmentation faults.

----------

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

From report at bugs.python.org  Thu Dec  2 03:19:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 02:19:09 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291197985.58.0.52800759882.issue3243@psf.upfronthosting.co.za>
Message-ID: <20101202021857.GA1873@rubuntu>


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

On Wed, Dec 01, 2010 at 10:06:25AM +0000, Antoine Pitrou wrote:
> +        try:
> +           self.sock.sendall(data)
> 
> Indentation problem here.

I could notice it now. Shall fix it.

> 
> +                if isinstance(data,str):
> +                    content_length = len(data)
> 
> I'm not sure I understand. What does sending an unicode string mean?

That's my mistake with understanding, I just realized (again) that
socket.send, socket.sendall does only bytes. And we don't encode the
unicode code string to send as bytes too.

> +        def iterable_body():
> +            yield "one"
> +            yield "two"
> +            yield "three"
> 
> Iterables of strings? this doesn't seem supported in the patch.

It should be:

+            yield b"one"
+            yield b"two"
+            yield b"three"

----------

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

From report at bugs.python.org  Thu Dec  2 03:23:20 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 02:23:20 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291215416.28.0.0920358124785.issue3243@psf.upfronthosting.co.za>
Message-ID: <20101202022312.GB1873@rubuntu>


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

On Wed, Dec 01, 2010 at 02:56:56PM +0000, Xuanji Li wrote:
> orsenthil: Hi, i don't quite understand why iter() needs to be
> called explicitly on data? As I understand it, if data is an
> iterable then you can use a for loop on it directly.
> 

The reasoning I followed was, data is an "Iterable" (a collection) and
you get an "Iterator" by passing via iter(). And you send the items by
looping over the iterator.

Honestly, I am not sure if iter is needed here too. I thought it was
not needed too, when you determine it is an Iterable and iterate over
it using the for loop. But I kept the iter() method just to create an
instance and send it.

Antoine, which would be the correct/ better?

----------

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

From orsenthil at gmail.com  Thu Dec  2 03:40:43 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 2 Dec 2010 10:40:43 +0800
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291223302.3569.3.camel@localhost.localdomain>
References: <1291218630.37.0.938665794504.issue3243@psf.upfronthosting.co.za>
	<1291223302.3569.3.camel@localhost.localdomain>
Message-ID: <20101202024043.GC1873@rubuntu>

On Wed, Dec 01, 2010 at 05:08:26PM +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> > if not request.has_header('Content-length'):
> >     if (not hasattr(data, '__read__') and 
> 
> What is __read__ supposed to be?

I don't think is required. The previous 2.x version patch was doing
this just to ensure that it is not file object and then it is a
sequence. (I could not understand why)

Now, when you determine that the sequence can be bytes, bytearray or
array.array then testing for memory view is enough. File objects
without Content-Length would raise an Exception too.

> > 2) Can call len but not buffer: assume len == #bytes
> 
> Why do you need it at all?
> 
Not required. For the same reason as above.

From report at bugs.python.org  Thu Dec  2 03:40:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 02:40:52 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291223302.3569.3.camel@localhost.localdomain>
Message-ID: <20101202024043.GC1873@rubuntu>


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

On Wed, Dec 01, 2010 at 05:08:26PM +0000, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at free.fr> added the comment:
> > if not request.has_header('Content-length'):
> >     if (not hasattr(data, '__read__') and 
> 
> What is __read__ supposed to be?

I don't think is required. The previous 2.x version patch was doing
this just to ensure that it is not file object and then it is a
sequence. (I could not understand why)

Now, when you determine that the sequence can be bytes, bytearray or
array.array then testing for memory view is enough. File objects
without Content-Length would raise an Exception too.

Not required. For the same reason as above.

----------

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

From report at bugs.python.org  Thu Dec  2 03:43:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 02:43:30 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1291257810.17.0.470397042996.issue9611@psf.upfronthosting.co.za>


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

I agree that clamping is a nice solution, and attached patch implements it.

About the question of the loop: FileIO.readall() uses while(1) without checking for signals. It looks like new_buffersize() maximum size is not BIGCHUNK but (BIGCHUNK-1)*2:

        /* Keep doubling until we reach BIGCHUNK;
           then keep adding BIGCHUNK. */
        if (currentsize <= BIGCHUNK)
            return currentsize + currentsize;
        else
            return currentsize + BIGCHUNK;

Is it a bug? But (BIGCHUNK-1)*2 is always smaller than INT_MAX. So readall() isn't affected by this bug. Should it be patched?

posix.read() doesn't have the bug because it uses an "int" for the size.

----------
keywords: +patch
Added file: http://bugs.python.org/file19898/read_write_32bits.patch

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

From report at bugs.python.org  Thu Dec  2 03:45:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 02:45:11 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1291257911.54.0.482841921766.issue9611@psf.upfronthosting.co.za>


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

(oops, the patch contained unrelated changes: remove trailing spaces)

----------
Added file: http://bugs.python.org/file19899/read_write_32bits.patch

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

From report at bugs.python.org  Thu Dec  2 03:45:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 02:45:22 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1291257922.7.0.717915568887.issue9611@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19898/read_write_32bits.patch

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

From report at bugs.python.org  Thu Dec  2 03:51:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 02:51:32 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <20101202021857.GA1873@rubuntu>
Message-ID: <20101202025123.GD1873@rubuntu>


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

On Thu, Dec 02, 2010 at 02:19:10AM +0000, Senthil Kumaran wrote:
> On Wed, Dec 01, 2010 at 10:06:25AM +0000, Antoine Pitrou wrote:
> > +        try:
> > +           self.sock.sendall(data)
> > 
> > Indentation problem here.
> 
> I could notice it now. Shall fix it.

Sorry, there was not any, if you viewed the patch online, it looked
as if there was, but not really. (I was surprised as how it could be
and not be caught by tests in the first place).

----------

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

From report at bugs.python.org  Thu Dec  2 04:08:55 2010
From: report at bugs.python.org (Xuanji Li)
Date: Thu, 02 Dec 2010 03:08:55 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291259335.99.0.911022741296.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

> > 2) Can call len but not buffer: assume len == #bytes

> Why do you need it at all?

Hmm, I'm looking at the the tests in urllib2 that fail if we omit this... in test_urllib2 there are tests that do this:

req = Request("http://example.com/", "")

and they expect Content-Length to be set to 0...

----------

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

From report at bugs.python.org  Thu Dec  2 04:14:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 03:14:13 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291259653.05.0.5450688657.issue3243@psf.upfronthosting.co.za>


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

Updated patch after correcting the mistake (bytes vs str) in the previous one.

----------
Added file: http://bugs.python.org/file19900/Issue3243-6.patch

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

From orsenthil at gmail.com  Thu Dec  2 04:15:27 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 2 Dec 2010 11:15:27 +0800
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291259335.99.0.911022741296.issue3243@psf.upfronthosting.co.za>
References: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
	<1291259335.99.0.911022741296.issue3243@psf.upfronthosting.co.za>
Message-ID: <20101202031527.GA2747@rubuntu>

On Thu, Dec 02, 2010 at 03:08:55AM +0000, Xuanji Li wrote:
> 
> req = Request("http://example.com/", "")

That should be:

> req = Request("http://example.com/", b"")

I updated some of those in the latest updated patch.


From report at bugs.python.org  Thu Dec  2 04:15:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 03:15:50 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291259335.99.0.911022741296.issue3243@psf.upfronthosting.co.za>
Message-ID: <20101202031527.GA2747@rubuntu>


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

On Thu, Dec 02, 2010 at 03:08:55AM +0000, Xuanji Li wrote:
> 
> req = Request("http://example.com/", "")

That should be:

> req = Request("http://example.com/", b"")

I updated some of those in the latest updated patch.

----------

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

From report at bugs.python.org  Thu Dec  2 04:16:52 2010
From: report at bugs.python.org (Xuanji Li)
Date: Thu, 02 Dec 2010 03:16:52 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291259812.47.0.330543777935.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

And my version too...

----------
Added file: http://bugs.python.org/file19901/issue_3243_py3k_6.patch

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

From report at bugs.python.org  Thu Dec  2 04:17:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 03:17:18 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1291259838.14.0.896449642757.issue10464@psf.upfronthosting.co.za>


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

Committed to py3k in r86925, 3.1 in r86926, and 2.7 in r86927.

Thanks for the patch, Xuanji.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 04:20:05 2010
From: report at bugs.python.org (Xuanji Li)
Date: Thu, 02 Dec 2010 03:20:05 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291260005.44.0.577471447232.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Actually I don't think you can go around changing test_urllib2.py, they are after all regression tests... and surely some users will send "" as data.

My patch handles the case of 0-length data specially, removing the need for 2) Can call len but not buffer: assume len == #bytes

----------

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

From report at bugs.python.org  Thu Dec  2 04:23:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 03:23:01 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291259812.47.0.330543777935.issue3243@psf.upfronthosting.co.za>
Message-ID: <20101202032220.GB2747@rubuntu>


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

On Thu, Dec 02, 2010 at 03:16:53AM +0000, Xuanji Li wrote:
> And my version too...
> 

+                if hasattr(data, '__len__') and not len(data):
+                    request.add_unredirected_header('Content-length', '0')

This is very special case. It should not be so. There was wrong
examples in the test_urllib2 which I just corrected.

Expect for the difference in (it = iter(data) - Which I am seeking
some advice too). Rest of the things in both patches are same.

Thank you.

----------

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

From report at bugs.python.org  Thu Dec  2 04:23:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 03:23:46 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291260005.44.0.577471447232.issue3243@psf.upfronthosting.co.za>
Message-ID: <20101202032336.GC2747@rubuntu>


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

On Thu, Dec 02, 2010 at 03:20:05AM +0000, Xuanji Li wrote:
> Actually I don't think you can go around changing test_urllib2.py,
> they are after all regression tests... and surely some users will
> send "" as data.
> 

Think about it this way. In py3k, socket.send can handle only bytes,
not string. So sending "" as data to the socket.send is wrong.

----------

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

From report at bugs.python.org  Thu Dec  2 04:28:47 2010
From: report at bugs.python.org (Xuanji Li)
Date: Thu, 02 Dec 2010 03:28:47 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291260527.46.0.466100705537.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

thought of a better way, we can check if data is true; this will cover "" and b"". this is in issue_3243_py3k_7.patch

----------
Added file: http://bugs.python.org/file19902/issue_3243_py3k_7.patch

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

From report at bugs.python.org  Thu Dec  2 04:45:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 02 Dec 2010 03:45:34 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <20101202032220.GB2747@rubuntu>
Message-ID: <20101202034523.GE2747@rubuntu>


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

Glaring at my mistakes.

> There was wrong examples in the test_urllib2 which I just corrected.

There were..

> Expect for the difference in (it = iter(data) - Which I am seeking

Except for ...

----------

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

From report at bugs.python.org  Thu Dec  2 05:36:54 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 02 Dec 2010 04:36:54 +0000
Subject: [issue9573] importing a module that executes fork() raises
	RuntimeError
In-Reply-To: <1281570124.9.0.596338600617.issue9573@psf.upfronthosting.co.za>
Message-ID: <1291264614.7.0.639921284544.issue9573@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed for 3.2 in r86928.

The fix has not been backported to 3.1, since it depends on the fix for issue 7242 (r78527) which was itself never backported to 3.1 after being forward ported to the py3k branch as part of a bulk merge (r83318)

Backporting to 2.7 would also be a manual process (although much easier, since issue 7242 is already fixed in that branch)

Given the obscurity of the error, I'm going to close this as fixed without backporting it. Anyone that wants it fixed in the 2.7 and 3.1 maintenance branches is free to develop and post the requisite patches :)

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

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

From report at bugs.python.org  Thu Dec  2 05:38:57 2010
From: report at bugs.python.org (Alex Earl)
Date: Thu, 02 Dec 2010 04:38:57 +0000
Subject: [issue10602] csv test_register_kwargs has invalid message parameters
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>


New submission from Alex Earl <slide.o.mix at gmail.com>:

in test_csv.py, the follow test is declared.

def test_register_kwargs(self):
    name = 'fedcba'
    csv.register_dialect(name, delimiter=';')
    try:
        self.assertTrue(csv.get_dialect(name).delimiter, '\t')
        self.assertTrue(list(csv.reader('X;Y;Z', name)), ['X', 'Y', 'Z'])
    finally:
        csv.unregister_dialect(name)

The assertTrue method take an expression to test for "true" and a message to display if that expression is false. If the test's goal is to test that delimiter is set so it's not None, then it will output a tab if the test fails. On the second line, the list would be displayed if the list returned from the reader is an empty list. The result of the reader operation is not the list on the right side anyway.


>>> list(csv.reader('X;Y;Z', name))
[['X'], ['', ''], ['Y'], ['', ''], ['Z']]

----------
messages: 123055
nosy: Alex.Earl
priority: normal
severity: normal
status: open
title: csv test_register_kwargs has invalid message parameters
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Dec  2 06:22:33 2010
From: report at bugs.python.org (Campbell Barton)
Date: Thu, 02 Dec 2010 05:22:33 +0000
Subject: [issue10600] surrogateescape'd paths not readable on Windows XP.
In-Reply-To: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za>
Message-ID: <1291267353.12.0.377053449876.issue10600@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

This bug is with blender3d, were the paths are stored internally in C as simple char arrays - bytes.

We could expose all path names as bytes too through our C/python API, this would at least be a 1:1 mapping, however Id prefer using strings if possible.

Since blender projects need to be portable - compress entire projects and run on different systems, we cant ensure the native fs encoding is used.

So surrogateescape seems to work very well, except for this one case I've run into, windows only.

----------

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

From report at bugs.python.org  Thu Dec  2 07:14:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 02 Dec 2010 06:14:05 +0000
Subject: [issue10600] surrogateescape'd paths not readable on Windows XP.
In-Reply-To: <1291245896.91.0.824091264043.issue10600@psf.upfronthosting.co.za>
Message-ID: <1291270445.75.0.206587362426.issue10600@psf.upfronthosting.co.za>


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

This is not a bug. You can't expect that using an arbitrary codec (such as UTF-8) with the surrogateescape code, and expect to be able that opening the file will be able to produce the correct filename. This won't work on Unix, in the general case, either. The surrogateescape code will work correctly in this setup only when used with the filesystem encoding.

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

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

From report at bugs.python.org  Thu Dec  2 07:59:31 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 02 Dec 2010 06:59:31 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1291273171.38.0.212698276713.issue10482@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Here's an updated _writerthread idea that handles more cases:

    def _writerthread(self, fhr, fhw, length=None):
        if length is None:
            flag = True
            while flag:
                buf = fhr.read( 512 )
                fhw.write( buf )
                if len( buf ) == 0:
                    flag = False
        else:
            while length > 0:
                buf = fhr.read( min( 512, length ))
                fhw.write( buf )
                length -= len( buf )
        # throw away additional data [see bug #427345]
        while select.select([fhr._sock], [], [], 0)[0]:
            if not fhr._sock.recv(1):
                break
        fhw.close()

----------

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

From report at bugs.python.org  Thu Dec  2 08:02:47 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 02 Dec 2010 07:02:47 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1291273367.17.0.253731671169.issue10482@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Sorry, left some extraneous code in the last message, here is the right code:

    def _writerthread(self, fhr, fhw, length=None):
        if length is None:
            flag = True
            while flag:
                buf = fhr.read( 512 )
                fhw.write( buf )
                if len( buf ) == 0:
                    flag = False
        else:
            while length > 0:
                buf = fhr.read( min( 512, length ))
                fhw.write( buf )
                length -= len( buf )
        fhw.close()

----------

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

From report at bugs.python.org  Thu Dec  2 08:08:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Dec 2010 07:08:25 +0000
Subject: [issue9299] os.makedirs(): Add a keyword argument to suppress "File
	exists" exception
In-Reply-To: <1279529255.89.0.917982060428.issue9299@psf.upfronthosting.co.za>
Message-ID: <1291273705.97.0.044701953651.issue9299@psf.upfronthosting.co.za>


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

I removed trailing '\' and whitespace, refreshed against current repository, removing conflicts, and committed. r86930

----------
assignee: georg.brandl -> terry.reedy
resolution: accepted -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 08:40:14 2010
From: report at bugs.python.org (Thomas Klausner)
Date: Thu, 02 Dec 2010 07:40:14 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1291275614.59.0.39568958876.issue10047@psf.upfronthosting.co.za>


Thomas Klausner <tk at giga.or.at> added the comment:

I've updated the operating system to a 5.99.39, and the problem disappeared. Strange. Thanks for the suggestions.

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

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

From report at bugs.python.org  Thu Dec  2 11:04:15 2010
From: report at bugs.python.org (Joshua Lock)
Date: Thu, 02 Dec 2010 10:04:15 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291284255.13.0.132002894325.issue8194@psf.upfronthosting.co.za>


Changes by Joshua Lock <incandescant at gmail.com>:


----------
nosy: +joshual

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

From report at bugs.python.org  Thu Dec  2 11:47:03 2010
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 02 Dec 2010 10:47:03 +0000
Subject: [issue10598] curses fails to import on Solaris
In-Reply-To: <1291234378.99.0.641306252968.issue10598@psf.upfronthosting.co.za>
Message-ID: <1291286823.6.0.928077703285.issue10598@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

I have attached a fix and a regression test.

----------
keywords: +patch
nosy: +lehmannro
Added file: http://bugs.python.org/file19903/issue10598.patch

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

From report at bugs.python.org  Thu Dec  2 12:16:41 2010
From: report at bugs.python.org (Campbell Barton)
Date: Thu, 02 Dec 2010 11:16:41 +0000
Subject: [issue10603] __file__ not usable, with certain paths on windows XP.
In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>
Message-ID: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

# create this path.
# it could be made by any application but including this line
# so encoding is not confused.
# c:\???
__import__("os").mkdir(b'c:\\\xe4\xf6\xfc')

# Now create a new script and save in the newly created dir
c:\???\test.py

# In c:\???\test.py add the following line
__import__("os").listdir(os.path.dirname(__file__))


# Now run the script from the command line using its absolute path.
c:\Python31\python.exe c:\???\test.py

--- This gives an error.
Traceback (most recent call last):
  File "m:\\xc3\xa4\xc3\xb6\xc3?\test.py", line 2, in <module>
WindowsError: [Error 3] The system cannot find the path specified: 'm:\\\xc3\xa4\xc3\xb6\xc3?\\*.*'


This is a bug because a script should be able to inspect the path where it is located.

----------
components: Interpreter Core
messages: 123063
nosy: ideasman42
priority: normal
severity: normal
status: open
title: __file__ not usable, with certain paths on windows XP.
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Dec  2 12:51:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 11:51:11 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291290671.11.0.377504268205.issue10602@psf.upfronthosting.co.za>


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

Thank you for the report.  The problem is that asserTrue is used instead of assertEqual; attached patch fixes that and reveals a bug.

----------
components: +Library (Lib)
nosy: +eric.araujo
stage:  -> needs patch
title: csv test_register_kwargs has invalid message parameters -> Wrong assert* method in test_csv.test_register_kwargs masks error
versions: +Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Thu Dec  2 12:52:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 11:52:55 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291290775.57.0.810083140095.issue10602@psf.upfronthosting.co.za>


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

This is the output of the test:

FAIL: test_register_kwargs (__main__.TestDialectRegistry)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_csv.py", line 326, in test_register_kwargs
    self.assertEqual(list(csv.reader('X;Y;Z', name)), ['X', 'Y', 'Z'])

- [['X'], ['', ''], ['Y'], ['', ''], ['Z']]
+ ['X', 'Y', 'Z']

Do you want to write a fix for this bug?

----------
keywords: +patch
Added file: http://bugs.python.org/file19904/fix-test.diff

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

From report at bugs.python.org  Thu Dec  2 13:21:36 2010
From: report at bugs.python.org (Alex Earl)
Date: Thu, 02 Dec 2010 12:21:36 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291292496.01.0.285200542688.issue10602@psf.upfronthosting.co.za>


Alex Earl <slide.o.mix at gmail.com> added the comment:

The internal _csv module which actually implements the reader method expects the first parameter to be an iterable object. Since strings are iterated by character, that is why this is occuring. So, the fix would need to be made in the _csv module, which is a C module. Would a valid fix be to check if the first parameter is a string and then iterate differently?

Also, the first test, which checks if the delimiter should be assertNotEqual if you are testing for '\t'. A better test might be to test to make sure that the default delimiter is not being set (','). So, it might be better to 

self.assertNotEqual(css.get_dialect(name).delimiter, ',')

or something similar.

----------

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

From report at bugs.python.org  Thu Dec  2 13:32:35 2010
From: report at bugs.python.org (Daniel Molkentin)
Date: Thu, 02 Dec 2010 12:32:35 +0000
Subject: [issue10604] Allocating too much memory for pathes
In-Reply-To: <1291293155.82.0.689283650387.issue10604@psf.upfronthosting.co.za>
Message-ID: <1291293155.82.0.689283650387.issue10604@psf.upfronthosting.co.za>


New submission from Daniel Molkentin <daniel at molkentin.de>:

from PC/getpathp.c:538


    if (pythonhome != NULL) {
        char *p;
        bufsz = 1;
        for (p = PYTHONPATH; *p; p++) {
            if (*p == DELIM)
                bufsz++; /* number of DELIM plus one */
        }
        bufsz *= strlen(pythonhome);
    }

The second last line should probably read

        bufsz += strlen(pythonhome);

----------
components: Windows
messages: 123067
nosy: danimo
priority: normal
severity: normal
status: open
title: Allocating too much memory for pathes
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  2 13:40:53 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Dec 2010 12:40:53 +0000
Subject: [issue10604] Allocating too much memory for pathes
In-Reply-To: <1291293155.82.0.689283650387.issue10604@psf.upfronthosting.co.za>
Message-ID: <1291293653.96.0.569545904662.issue10604@psf.upfronthosting.co.za>


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

Hmm, not sure.
Try with 
   set PYTHONPATH=.\a;.\b
sys.path will contains the entries:
   <current_dir>\a
   <current_dir>\b
a multiplication seems necessary.

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

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

From report at bugs.python.org  Thu Dec  2 13:47:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 12:47:03 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291294023.72.0.203169188913.issue3243@psf.upfronthosting.co.za>


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

>> What is __read__ supposed to be?
> I don't think is required.

The point is that Python does not define a __read__ magic method.  Only read exists, on file objects.

----------

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

From report at bugs.python.org  Thu Dec  2 14:25:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Dec 2010 13:25:45 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1291250331.44.0.20647116632.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291296340.3576.1.camel@localhost.localdomain>


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

> Just wanted to post this so there weren't any illusions about the
> patch being a big win.

Daniel has already posted benchmark numbers, I would trust them rather
than any theoretical speculation about whether the patch is interesting
or not.

----------

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

From report at bugs.python.org  Thu Dec  2 14:42:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 13:42:29 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291297349.68.0.589956942038.issue10602@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19904/fix-test.diff

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

From report at bugs.python.org  Thu Dec  2 14:43:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 13:43:23 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291297403.9.0.757321463778.issue10602@psf.upfronthosting.co.za>


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

I still think this is a bug in the test.  Attached patch fixes it.

----------
assignee:  -> eric.araujo
Added file: http://bugs.python.org/file19905/fix-test.diff

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

From report at bugs.python.org  Thu Dec  2 14:55:20 2010
From: report at bugs.python.org (Anurag Chourasia)
Date: Thu, 02 Dec 2010 13:55:20 +0000
Subject: [issue10555] AIX 5.3 - GCC - Python 2.7 Shared Library Support -
	Fatal Python error: Interpreter not initialized (version mismatch?)
In-Reply-To: <1290894123.11.0.895090468889.issue10555@psf.upfronthosting.co.za>
Message-ID: <1291298120.56.0.689024350418.issue10555@psf.upfronthosting.co.za>


Anurag Chourasia <anurag.chourasia at gmail.com> added the comment:

Hi All,

Thanks again for all your support.

I can confirm that this works fine with the AIX Shared Library build support added in Python 2.7.1 (and 3.x which I have not tested but my tests with 2.7.1 were absolutely fine)

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

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

From report at bugs.python.org  Thu Dec  2 15:12:28 2010
From: report at bugs.python.org (Xuanji Li)
Date: Thu, 02 Dec 2010 14:12:28 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291299148.93.0.092056554852.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

eric: sorry, that has been fixed in issue_3243_py3k_7.patch

----------

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

From report at bugs.python.org  Thu Dec  2 15:13:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 14:13:13 +0000
Subject: [issue10603] __file__ not usable, with certain paths on windows XP.
In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>
Message-ID: <1291299193.56.0.885570063312.issue10603@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/issue10603>
_______________________________________

From report at bugs.python.org  Thu Dec  2 15:14:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 14:14:23 +0000
Subject: [issue10603] __file__ not usable, with certain paths on windows XP.
In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>
Message-ID: <1291299263.66.0.280713676399.issue10603@psf.upfronthosting.co.za>


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

Much work has been done on non-ASCII paths in 3.2.  Can you test this with the 3.2 alpha and let us know the results?

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

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

From report at bugs.python.org  Thu Dec  2 15:28:31 2010
From: report at bugs.python.org (Alex Earl)
Date: Thu, 02 Dec 2010 14:28:31 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291300111.94.0.412914371002.issue10602@psf.upfronthosting.co.za>


Alex Earl <slide.o.mix at gmail.com> added the comment:

The patch looks good to me. The only question I have is that the previous test that was passing a string, is the expected behavior what was being returned before, or would it be useful to turn the string into an iterable over "lines"?

----------

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

From report at bugs.python.org  Thu Dec  2 15:51:17 2010
From: report at bugs.python.org (Adrian Nye)
Date: Thu, 02 Dec 2010 14:51:17 +0000
Subject: [issue10605] ElementTree documentation
In-Reply-To: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za>
Message-ID: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za>


New submission from Adrian Nye <adrian_nye at yahoo.com>:

TreeBuilder doc does not mention its "entity" argument which is the main way to deal with html entity encodings which are unfortunately a common problem in XML.

Also the doc needs a discussion of the relationship of TreeBuilder and XMLParser.   The former has "entity", and the latter has "encoding", but
what happens is you need both?   Needs examples of using these two classes.

----------
components: XML
messages: 123076
nosy: adrian_nye
priority: normal
severity: normal
status: open
title: ElementTree documentation
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  2 16:03:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 15:03:02 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291302182.74.0.101466914958.issue10602@psf.upfronthosting.co.za>


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

I don?t think we should change behavior.  Strings are iterable; csv.reader takes an iterable; this is sensible and documented.  See http://docs.python.org/dev/library/csv#csv.reader and the last example of http://docs.python.org/dev/library/csv#examples

----------

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

From report at bugs.python.org  Thu Dec  2 16:11:35 2010
From: report at bugs.python.org (Alex Earl)
Date: Thu, 02 Dec 2010 15:11:35 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291302695.3.0.57377011833.issue10602@psf.upfronthosting.co.za>


Alex Earl <slide.o.mix at gmail.com> added the comment:

Excellent. As long as it's documented, it works for me.

----------

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

From report at bugs.python.org  Thu Dec  2 17:17:02 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 02 Dec 2010 16:17:02 +0000
Subject: [issue10606] Misspelling of Jamie Zawinski's surname in urllib.parse
	docstring
In-Reply-To: <1291306622.05.0.84644269608.issue10606@psf.upfronthosting.co.za>
Message-ID: <1291306622.05.0.84644269608.issue10606@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

(was misspelled when issue 5650 was fixed, FWIW)

----------
assignee: orsenthil
components: Library (Lib)
files: py3k-fix-jwz-surname.patch
keywords: patch
messages: 123079
nosy: dmalcolm, orsenthil
priority: low
severity: normal
status: open
title: Misspelling of Jamie Zawinski's surname in urllib.parse docstring
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19906/py3k-fix-jwz-surname.patch

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

From report at bugs.python.org  Thu Dec  2 17:24:20 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 02 Dec 2010 16:24:20 +0000
Subject: [issue10607] Document of PyOS_(v)snprintf is wrong.
In-Reply-To: <1291307060.85.0.577085491194.issue10607@psf.upfronthosting.co.za>
Message-ID: <1291307060.85.0.577085491194.issue10607@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/conversion.html#PyOS_vsnprintf

"the buffer size needed to avoid truncation exceeds size by more than 512 bytes, Python aborts with a Py_FatalError."

I think ":cfunc:`vsprintf`'s output exeeds the buffer need to truncation that have *size* + 512byte length," is correct.

----------
assignee: docs at python
components: Documentation
messages: 123080
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Document of PyOS_(v)snprintf is wrong.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Dec  2 17:43:35 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 02 Dec 2010 16:43:35 +0000
Subject: [issue10606] Misspelling of Jamie Zawinski's surname in urllib.parse
	docstring
In-Reply-To: <1291306622.05.0.84644269608.issue10606@psf.upfronthosting.co.za>
Message-ID: <1291308215.99.0.877591532544.issue10606@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Fixed in py3k in r86932

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

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

From report at bugs.python.org  Thu Dec  2 18:31:43 2010
From: report at bugs.python.org (Alex Rodriguez)
Date: Thu, 02 Dec 2010 17:31:43 +0000
Subject: [issue9227] can't import Tkinter / use IDLE after installing Python
	2.7 on Mac OS X
In-Reply-To: <1278883906.89.0.545374403914.issue9227@psf.upfronthosting.co.za>
Message-ID: <1291311103.42.0.220778446658.issue9227@psf.upfronthosting.co.za>


Alex Rodriguez <alejmrm at gmail.com> added the comment:

I downloaded "python-2.7.1-macosx10.6.dmg" file and tested if Tkinter and IDLE still have same issue reported here and I did not find anymore this issue.

I was able to launch IDLE and create a Tkinter GUI. From my side we can resolve and close this issue.

----------

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

From report at bugs.python.org  Thu Dec  2 18:32:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Dec 2010 17:32:02 +0000
Subject: [issue9299] os.makedirs(): Add a keyword argument to suppress "File
	exists" exception
In-Reply-To: <1279529255.89.0.917982060428.issue9299@psf.upfronthosting.co.za>
Message-ID: <1291311122.54.0.562200474989.issue9299@psf.upfronthosting.co.za>


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

Georg Brandl patched the doc changes in r86931.
Ray, for future reference, you might take a look, particularly 

-.. function:: makedirs(path[, mode][, exist_ok=False])
+.. function:: makedirs(path, mode=0o777, exist_ok=False)

In 3.x, (as opposed to 2.x), the style for params with default args is to give the default if possible, *without* [] now, so the signature in the doc looks as in a def statement. I, of course, missed this.

----------

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

From report at bugs.python.org  Thu Dec  2 18:34:01 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 02 Dec 2010 17:34:01 +0000
Subject: [issue10607] Document of PyOS_(v)snprintf is wrong.
In-Reply-To: <1291307060.85.0.577085491194.issue10607@psf.upfronthosting.co.za>
Message-ID: <1291311241.63.0.70218371149.issue10607@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Sorry, I've misreaded the sentence.

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

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

From report at bugs.python.org  Thu Dec  2 18:35:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 17:35:48 +0000
Subject: [issue10604] Allocating too much memory for pathes
In-Reply-To: <1291293155.82.0.689283650387.issue10604@psf.upfronthosting.co.za>
Message-ID: <1291311348.41.0.0296813545195.issue10604@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Before the multiplication, "bufsz" is not aptly named: as your snippet shows it's counting the number of delimiters in the PYTHONPATH.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 18:37:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 17:37:18 +0000
Subject: [issue9299] os.makedirs(): Add a keyword argument to suppress "File
	exists" exception
In-Reply-To: <1279529255.89.0.917982060428.issue9299@psf.upfronthosting.co.za>
Message-ID: <1291311438.77.0.132456445502.issue9299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, you're not to blame since the patch merely extended the definition which was still using obsolete syntax anyway.

----------

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

From report at bugs.python.org  Thu Dec  2 18:38:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 17:38:31 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291311511.19.0.80649786553.issue10557@psf.upfronthosting.co.za>


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

I am submitting a patch (issue10557b.diff) for commit review.  As Marc suggested, decimal conversion is now performed on Py_UNICODE characters. For this purpose, I introduced _PyUnicode_NormalizeDecimal() function that takes Py_UNICODE and returns a PyUnicode object with whitespace stripped and non-ASCII digits converted to ASCII equivalents.  The PyUnicode_EncodeDecimal() function is no longer used and I added a comment recommending that _PyUnicode_NormalizeDecimal() be used instead. I would like to eventually remove PyUnicode_EncodeDecimal(), but I amd not sure about the proper deprecation procedures for undocumented C APIs.

As a result, int(), float(), etc will no longer raise UnicodeDecodeError unless given a string with lone surrogates.  (This error comes from UTF-8 codec that is applied after digit normalization.)

A few error cases such as embedded '\0' and non-digit characters with ord(c) > 255 will now raise ValueError instead of UnicodeDecodeError.  Since UnicodeDecodeError is a subclass of ValueError, it is unlikely that existing code would attempt to differentiate between the two.  It is possible to achieve complete compatibility, but it is hard to justify reporting different error types on non-digit characters below and above code point 255.

The patch contains tests for error messages that I tried to make robust by only requiring that s.strip() be found somewhere in the error message from int(s).  Note that since in this patch whitespace is stripped before the string is passed to the parser, the parser errors do not contain the whitespace.  This may actually be desirable because it helps the user to see the source of the error without being distracted by irrelevant white space.

----------
assignee:  -> belopolsky
stage: unit test needed -> commit review

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

From report at bugs.python.org  Thu Dec  2 18:38:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 17:38:56 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291311536.63.0.374666476988.issue10557@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file19907/issue10557b.diff

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

From report at bugs.python.org  Thu Dec  2 18:54:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 17:54:31 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291312471.29.0.130265635062.issue10557@psf.upfronthosting.co.za>


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

Is the stripping of whitespace necessary for this fix?

Currently, the complex constructor accepts whitespace both inside and outside the (optional) parentheses:

>>> complex(' ( 2+3j ) ')
(2+3j)

The classes of whitespace accepted in each position are the same.  IIUC, with your patch, that consistency would be lost---is that right?

If the whitespace stripping isn't necessary then I'd prefer to leave that change for another issue.

----------

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

From report at bugs.python.org  Thu Dec  2 19:02:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 18:02:21 +0000
Subject: [issue10597] Py_SetPythonHome document shows same url twice.
In-Reply-To: <1291219651.16.0.0325545268519.issue10597@psf.upfronthosting.co.za>
Message-ID: <1291312941.39.0.996627498857.issue10597@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You can give "two" homes; prefix and exec_prefix.  r86933 now links to PYTHONHOME where this is already documented properly.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 19:08:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 18:08:12 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1291313292.4.0.0201298385465.issue7475@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Codecs brought back and (un)transform implemented in r86934.

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

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

From report at bugs.python.org  Thu Dec  2 19:08:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 18:08:30 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291313310.93.0.470484850539.issue10557@psf.upfronthosting.co.za>


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

Just to clarify:  I'm not opposed to allowing arbitrary Unicode whitespace in the float, int, complex constructors (indeed, it's probably a good thing).  But I'd like to see the change made consistently;  for the complex constructor this looks a bit involved, so it would probably be cleaner to have a separate patch to make the whitespace changes.

----------

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

From report at bugs.python.org  Thu Dec  2 19:11:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Dec 2010 18:11:48 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291313508.14.0.571803280626.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

AP: I've already given my blessing to the patch.
Just wanted to note what the existing code did.
I also trust timings but recognize that they
reflect a particular build configuration 
(compiler/processor/o.s)and the usage pattern 
for a particular benchmark.

----------

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

From report at bugs.python.org  Thu Dec  2 19:14:19 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Thu, 02 Dec 2010 18:14:19 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1291313659.05.0.620420958782.issue3132@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

For reference, Numpy's PEP 3118 implementation is here:

http://github.com/numpy/numpy/blob/master/numpy/core/_internal.py#L357

http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/buffer.c#L76

It would be a good idea to ensure that the numpy and struct implementations are in agreement about details of the format strings.
(I wouldn't take the Numpy implementation as the definitive one, though.)

- The "sub-structs" in Numpy arrays (in align=True mode) are aligned
  according to the maximum alignment of the fields.

- I assumed the 'O' format in the PEP is supposed to be similar to Numpy
  object arrays. This implies some reference counting semantics. The
  Numpy PEP 3118 implementation assumes the memory contains borrowed
  references, valid at least until the buffer is released.
  Unpacking 'O' should probably INCREF whatever PyObject* pointer is
  there.

- I assumed the alignment specifiers were unscoped. I'm not sure
  however whether this is the best thing to do.

- The function pointers and pointers to pointers were not implemented.
  (Numpy cannot represent those as data types.)

----------
nosy: +pv

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

From report at bugs.python.org  Thu Dec  2 19:28:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 18:28:27 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1291312471.29.0.130265635062.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTinFfJeUwPew_cb-PTGqyP6iFiSXft3U8BrR=Gkv@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 12:54 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> The classes of whitespace accepted in each position are the same. ?IIUC, with your patch,
> that consistency would be lost---is that right?

Good point. I thought The PyUnicode_EncodeDecimal() was stripping the
space, but it was converting it to ASCII ' ' instead.  That's easy to
fix.   Can you suggest a test case?

----------

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

From report at bugs.python.org  Thu Dec  2 19:28:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 18:28:58 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <AANLkTinFfJeUwPew_cb-PTGqyP6iFiSXft3U8BrR=Gkv@mail.gmail.com>
Message-ID: <AANLkTimiJ3EABNNn7eGLrEW275aK=hFVC8tZEu6P8XM2@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 1:28 PM, Alexander Belopolsky
<belopolsky at users.sourceforge.net> wrote:
..
>  Can you suggest a test case?

I mean for complex().

----------

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

From report at bugs.python.org  Thu Dec  2 19:30:33 2010
From: report at bugs.python.org (Matt Bond)
Date: Thu, 02 Dec 2010 18:30:33 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1291314633.52.0.701393668505.issue9621@psf.upfronthosting.co.za>


Matt Bond <gmattbond at gmail.com> added the comment:

Sorry for the delay in responding, and for getting this patch cleaned up and submitted.

While I was going through my code to submit it, I found a couple of additional issues with it. Then I ended up becoming very busy with my grad courses. As a result, I haven't had a chance to do anything with it. Currently, my plan is to rework it over the winter break to fix the issues, make it work correctly with python 3, and remove the dependence on the external graphviz package (which should resolve the import issue as well).

----------

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

From report at bugs.python.org  Thu Dec  2 19:33:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Dec 2010 18:33:19 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1291314799.46.0.0885727361001.issue9333@psf.upfronthosting.co.za>


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

Fixed in r86935.

Tests pass on the following setups:
- Windows 7 (regular user - no symlink privilege)
- Windows 7 (administrator + symlink privilege)
- Windows Server 2003 (no symlink abilities)
- Arch Linux (just a sanity check)

I'm going to create a follow-up issue to explain how this works for the Windows part of the FAQ. There is documentation, but beginners could probably use some tips and explanation.

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

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

From report at bugs.python.org  Thu Dec  2 19:35:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 02 Dec 2010 18:35:29 +0000
Subject: [issue9227] can't import Tkinter / use IDLE after installing Python
	2.7 on Mac OS X
In-Reply-To: <1278883906.89.0.545374403914.issue9227@psf.upfronthosting.co.za>
Message-ID: <1291314929.33.0.446188032652.issue9227@psf.upfronthosting.co.za>


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

Works for me too. Great!

----------

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

From report at bugs.python.org  Thu Dec  2 19:42:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Dec 2010 18:42:13 +0000
Subject: [issue10608] Add a section to Windows FAQ explaining os.symlink
In-Reply-To: <1291315333.59.0.493313738075.issue10608@psf.upfronthosting.co.za>
Message-ID: <1291315333.59.0.493313738075.issue10608@psf.upfronthosting.co.za>


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

A section in the Windows FAQ should better explain the recent addition of os.symlink and how it can be used, along with examples.

If a user just sits down and hits Start>Run>python, os.symlink will almost positively not be available. I'll need to briefly explain privileges, which one is needed, how it can be obtained, and how to properly write code on Windows to make use of os.symlink.

There is documentation of os.symlink itself, but it's more of a developer reference to match the rest of the os module documentation. A beginner would likely need more information, but that information isn't right for Doc/library/os.rst.

----------
assignee: brian.curtin
components: Documentation, Windows
messages: 123099
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a section to Windows FAQ explaining os.symlink
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Dec  2 19:48:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 18:48:48 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1291315728.45.0.667398461437.issue10515@psf.upfronthosting.co.za>


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

Are you sure testA1 is correct?  It seems to me that in that case the sniffer can indeed not determine the delimiter, but I don't really understand the guessing algorithm.  The existing behavior on unquoted strings is...interesting :)

Also if you are willing to take the time it would be helpful to have the tests as a patch against test_csv.

----------
nosy: +r.david.murray, skip.montanaro

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

From report at bugs.python.org  Thu Dec  2 19:56:24 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 02 Dec 2010 18:56:24 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290979159.05.0.274230839033.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=+kpkBJSi_pPhjV7ZRnkWZU6XeQvZsOM_BBXyC@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

The imaginary unit 'i' should be equvivalent to the imaginary unit 'j'. The
imaginary unit, however, should be used consistently in the source code.

----------
Added file: http://bugs.python.org/file19908/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
The imaginary unit &#39;i&#39; should be equvivalent to the imaginary unit &#39;j&#39;. The imaginary unit, however, should be used consistently in the source code.

From report at bugs.python.org  Thu Dec  2 20:04:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Dec 2010 19:04:32 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291316672.89.0.654624942214.issue10562@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If this change were important, the numpy/scipy guys would have requested it long ago.  Any possible benefit would be slight and not at all worth the disruption.

   s.replace('j', 'i')

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Dec  2 20:20:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 19:20:08 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291317608.37.0.198288005931.issue10557@psf.upfronthosting.co.za>


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

Ah yes, you're right: this shouldn't be a hard fix. I withdraw my suggestion for a separate patch.  :-)

Checking that:

  complex('\xa0(\xa02+3j\xa0)\xa0') == complex(2.0, 3.0)

would probably be enough.

----------

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

From report at bugs.python.org  Thu Dec  2 20:38:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Dec 2010 19:38:02 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1291318682.32.0.242939794627.issue10535@psf.upfronthosting.co.za>


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

Here's a patch for the ResourceWarnings that were introduced.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file19909/warnings.diff

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

From report at bugs.python.org  Thu Dec  2 20:40:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 19:40:10 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291318810.85.0.116938218004.issue10562@psf.upfronthosting.co.za>


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

> There should be an environment variable to make the symbol settable.

That could work;  it's a bit late to do this in 3.2, though.  How about the following transition strategy for the complex output.

Python 3.3: Introduce PYTHONIMAGINARYSYMBOL environment variable (and possibly also a related command-line option to the interpreter?).

Python 3.4: Show a warning on startup if this environment variable isn't used.

Python 3.5: Make the environment variable mandatory.

Python 3.6: Make the environment variable optional again, but this time with the default output being 'i' rather than 'j'.

Python 3.7: Deprecate use of PYTHONIMAGINARYSYMBOL.  (Warning on startup if it's set.)

Python 3.8: Error on startup if PYTHONIMAGINARYSYMBOL is set.

Python 3.9: Go back to ignoring PYTHONIMAGINARYSYMBOL.

I'm sure we could find a compatible transition strategy for the complex *inputs*: (3.3: accept both 'i' and 'j';  3.6: warn about 'j' usage; 3.8 remove acceptance of 'j' on input).

----------

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

From report at bugs.python.org  Thu Dec  2 20:46:55 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 02 Dec 2010 19:46:55 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291318810.85.0.116938218004.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTimg93SnaXRwZPXyrGqPuGP8Pe5N7P217ZZvk+xk@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

That is acceptable, but way to slow for the 'j' imaginary unit to become
extinct. It should happen sooner.

----------
Added file: http://bugs.python.org/file19910/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
That is acceptable, but way to slow for the &#39;j&#39; imaginary unit to become extinct. It should happen sooner.

From report at bugs.python.org  Thu Dec  2 20:56:16 2010
From: report at bugs.python.org (Campbell Barton)
Date: Thu, 02 Dec 2010 19:56:16 +0000
Subject: [issue10603] __file__ not usable, with certain paths on windows XP.
In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>
Message-ID: <1291319776.93.0.245747596126.issue10603@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

This is fixed in 3.2a4.

----------

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

From report at bugs.python.org  Thu Dec  2 20:59:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 19:59:58 +0000
Subject: [issue10603] __file__ not usable, with certain paths on windows XP.
In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>
Message-ID: <1291319998.92.0.0449390120224.issue10603@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 21:28:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 20:28:22 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1291321702.36.0.231679833308.issue9621@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Thu Dec  2 21:30:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 20:30:37 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291321837.32.0.240080740702.issue10562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

We also should consider a good roadmap to account for the eventual support of quaternions in the language syntax.

Since the conventional mathematical symbols for the additional imaginary units of quaternions are j and k, confusion is bound to happen.

My preferred solution is to limit PYTHONIMAGINARYSYMBOL values to "i", "j" or "k" in Python 3.4.  The two additional imaginary unit symbols would then be a cyclic permutation of i,j,k, viz. for PYTHONIMAGINARYSYMBOL=j, the units are k and i.

This deterministic approach has the advantage that migration of code from one imaginary symbol to another is as easy as:

sed -e 's/k/l/' -e 's/j/k/' -e 's/i/j/' -e 's/l/i/'

provided that you restrict yourself not to use the characters i, j, k or l in identifiers, keywords or strings in the source code.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Dec  2 21:35:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 20:35:24 +0000
Subject: [issue10299] Add index with links section for built-in functions
In-Reply-To: <1288794298.88.0.884491179751.issue10299@psf.upfronthosting.co.za>
Message-ID: <1291322124.87.0.424112196726.issue10299@psf.upfronthosting.co.za>


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

By the way, I wonder why this page is named ?functions? and the one for ?builtins? is nearly empty.

----------

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

From report at bugs.python.org  Thu Dec  2 21:41:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Dec 2010 20:41:08 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291321837.32.0.240080740702.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291322462.3576.45.camel@localhost.localdomain>


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

> Since the conventional mathematical symbols for the additional
> imaginary units of quaternions are j and k, confusion is bound to
> happen.
> 
> My preferred solution is to limit PYTHONIMAGINARYSYMBOL values to "i",
> "j" or "k" in Python 3.4.  The two additional imaginary unit symbols
> would then be a cyclic permutation of i,j,k, viz. for
> PYTHONIMAGINARYSYMBOL=j, the units are k and i.

Can we consider an environment variable to change the direction of the
permutation, e.g. PYTHONIMAGINARYPERMUTATIONDIR=-1?

Otherwise +11j from me.

----------

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

From report at bugs.python.org  Thu Dec  2 21:42:04 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Dec 2010 20:42:04 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291322524.47.0.839174672104.issue10562@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Since we have two distinct user groups (engineers and everyone else), it's clear that we should fork Python.  That would let each group work with their on most-natural-representation and it would prevent unnecessary configuration challenges.

Benjamin, could you please start a new branch and fork the website into python.i.org and python.j.org.

----------

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

From report at bugs.python.org  Thu Dec  2 21:45:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Dec 2010 20:45:08 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291322708.74.0.153982978876.issue10562@psf.upfronthosting.co.za>


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

Will PYTHONIMAGINARYPERMUTATIONDIR accept imaginary numbers? If so, we will also need PYTHONIMAGINARYPERMUTATIONDIRIMAGINARYIDENTIFIER.

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

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

From report at bugs.python.org  Thu Dec  2 21:52:06 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 02 Dec 2010 20:52:06 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following http://mail.python.org/pipermail/docs/2010-December/002356.html a possible solution is:


diff -r 3b07f7bb0289 Doc/library/dbm.rst
--- a/Doc/library/dbm.rst       Thu Dec 02 19:29:18 2010 +0100
+++ b/Doc/library/dbm.rst       Thu Dec 02 21:51:06 2010 +0100
@@ -88,7 +88,7 @@
 
    # Loop through contents.  Other dictionary methods
    # such as .keys(), .values() also work.
-   for k, v in db.iteritems():
+   for k, v in dict(db).items():
        print(k, '\t', v)
 
    # Storing a non-string key or value will raise an exception (most

How much ugly is this? alternatively, we can:


>>> for k in db.keys():
...     print(k, '\t', db.get(k))

What would be the best solution? (anyhow the comments above the for loop has to be changed).

Regards,
Sandro

----------
messages: 123113
nosy: sandro.tosi
priority: normal
severity: normal
status: open
title: dbm documentation example doesn't work (iteritems())

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

From report at bugs.python.org  Thu Dec  2 21:57:16 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 02 Dec 2010 20:57:16 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291322708.74.0.153982978876.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=6LT9J9ay07qNJtdsToGn4tn=31GpQSL+wt8CU@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

How did you implement the letter 'j' as the imaginary unit? Can you now
implement the letter 'i' to act as an imaginary unit? Is that possible? If
it's possible in MATLAB, why not have both 'j' and 'i' in Python as well?

----------
Added file: http://bugs.python.org/file19911/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
How did you implement the letter &#39;j&#39; as the imaginary unit? Can you now implement the letter &#39;i&#39; to act as an imaginary unit? Is that possible? If it&#39;s possible in MATLAB, why not have both &#39;j&#39; and &#39;i&#39; in Python as well?

From report at bugs.python.org  Thu Dec  2 22:06:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:06:42 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324002.61.0.225184093039.issue10562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I heard that MathWorks has a patent on METHOD AND APPARATUS FOR IMAGINATORIAL FREEDOM, so if that's true we might not be allowed to implement it.

----------

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

From report at bugs.python.org  Thu Dec  2 22:07:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:07:22 +0000
Subject: [issue10299] Add index with links section for built-in functions
In-Reply-To: <1288794298.88.0.884491179751.issue10299@psf.upfronthosting.co.za>
Message-ID: <1291324042.75.0.0863015805283.issue10299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's legacy from the good old latex days.

----------

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

From report at bugs.python.org  Thu Dec  2 22:13:22 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 02 Dec 2010 21:13:22 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291324002.61.0.225184093039.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTik3VY8cQK4ibmVCqBK26-ZjU5ac2yK+Wo2SsVym@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

"In electrical engineering<http://en.wikipedia.org/wiki/Electrical_engineering>
and
related fields, the imaginary unit is often denoted by *j* to avoid
confusion with electrical
current<http://en.wikipedia.org/wiki/Current_(electricity)> as
a function of time, traditionally denoted by *i*(*t*) or just *i*."
-Wikipedia

Does Python have to deal with electrical current as a function of time to
associate j with the imaginary unit and not i?

----------
Added file: http://bugs.python.org/file19912/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
<font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height: 19px;"><span class="Apple-style-span" style="font-size: 13px; ">&quot;In??<a href="http://en.wikipedia.org/wiki/Electrical_engineering" title="Electrical engineering" style="text-decoration: none; color: rgb(6, 69, 173); background-image: none; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: initial; background-position: initial initial; background-repeat: initial initial; ">electrical engineering</a>??and related fields, the imaginary unit is often denoted by??<i>j</i>??to avoid confusion with??<a href="http://en.wikipedia.org/wiki/Current_(electricity)" title="Current (electricity)" class="mw-redirect" style="text-decoration: none; color: rgb(6, 69, 173); background-image: none; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: initial; background-position: initial initial; background-repeat: initial initial; ">electrical current</a>??as a function of time, traditionally denoted by??<i>i</i>(<i>t</i>) or just??<i>i</i>.&quot; -Wikipedia</span></span></font><div>
<font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height: 19px;"><span class="Apple-style-span" style="font-size: 13px; "><br></span></span></font></div><div><font class="Apple-style-span" face="sans-serif"><span class="Apple-style-span" style="line-height: 19px;"><span class="Apple-style-span" style="font-size: 13px; ">Does Python have to deal with electrical current as a function of time to associate j with the imaginary unit and not i?</span></span></font></div>

From report at bugs.python.org  Thu Dec  2 22:14:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:14:38 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324478.27.0.2159157743.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19908/unnamed

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

From report at bugs.python.org  Thu Dec  2 22:14:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:14:41 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324481.88.0.364241056084.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19910/unnamed

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

From report at bugs.python.org  Thu Dec  2 22:14:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:14:44 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324484.75.0.137427304078.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19911/unnamed

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

From report at bugs.python.org  Thu Dec  2 22:14:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:14:48 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324488.93.0.65274869454.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19912/unnamed

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

From report at bugs.python.org  Thu Dec  2 22:14:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 02 Dec 2010 21:14:59 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324499.55.0.242096126958.issue10562@psf.upfronthosting.co.za>


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

yes

----------

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

From report at bugs.python.org  Thu Dec  2 22:16:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 21:16:19 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324579.13.0.867072158125.issue10562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sure.  I have personally written software where i denotes, in effect, an electrical current.

----------

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

From report at bugs.python.org  Thu Dec  2 22:21:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Dec 2010 21:21:41 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291324901.38.0.705679123297.issue10562@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Can you now implement the letter 'i' to act as an 
> imaginary unit? Is that possible?

Yes, it's possible; however, the developers do not think it is worthwhile.

> If it's possible in MATLAB, why not have both 'j' and 'i' 
> in Python as well?

Python does some things differently that MATLAB.  One design
choice is to avoid global configurations (such as number of
places displayed in a float) because modules written by
different people make make different assumptions or may
compete for a preferred setting.

Let's try to end this thread now.  It's a bit of no-win
situtation.  None of the core devs see enough possible
benefit to warrant the disruption it would cause.  Years
of Python being used in the scientific community has shown
that the current use of 'j' has not been a problem.

----------

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

From report at bugs.python.org  Thu Dec  2 22:24:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 02 Dec 2010 21:24:19 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291318810.85.0.116938218004.issue10562@psf.upfronthosting.co.za>
Message-ID: <4CF80E7F.5080201@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
>> There should be an environment variable to make the symbol settable.
> 
> That could work;  it's a bit late to do this in 3.2, though.  How about the following transition strategy for the complex output.
> 
> Python 3.3: Introduce PYTHONIMAGINARYSYMBOL environment variable (and possibly also a related command-line option to the interpreter?).
> 
> Python 3.4: Show a warning on startup if this environment variable isn't used.
> 
> Python 3.5: Make the environment variable mandatory.
> 
> Python 3.6: Make the environment variable optional again, but this time with the default output being 'i' rather than 'j'.
> 
> Python 3.7: Deprecate use of PYTHONIMAGINARYSYMBOL.  (Warning on startup if it's set.)
> 
> Python 3.8: Error on startup if PYTHONIMAGINARYSYMBOL is set.
> 
> Python 3.9: Go back to ignoring PYTHONIMAGINARYSYMBOL.
> 
> I'm sure we could find a compatible transition strategy for the complex *inputs*: (3.3: accept both 'i' and 'j';  3.6: warn about 'j' usage; 3.8 remove acceptance of 'j' on input).

Hmm, what calendar are you using ? April 1st is still a few months
away on the Gregorian one and even the Julian calendar isn't that far
off yet :-)

Why not simply support both for number constructors (and stick with
'j' for the language spec) ?

----------
nosy: +lemburg

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

From report at bugs.python.org  Thu Dec  2 22:33:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 21:33:28 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291325608.02.0.923899265835.issue10562@psf.upfronthosting.co.za>


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

In all seriousness, the idea of accepting both 'i' and 'j' in complex() isn't horrible. I'm personally -0.small on it, mostly because it seems likely to lead to more objections about the complex str() and repr() *output* containing 'j's.  I still think python-ideas would be a more appropriate place for that discussion, though.

----------

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

From report at bugs.python.org  Thu Dec  2 22:34:44 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 02 Dec 2010 21:34:44 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1291311511.19.0.80649786553.issue10557@psf.upfronthosting.co.za>
Message-ID: <4CF810F1.8060004@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I am submitting a patch (issue10557b.diff) for commit review.  As Marc suggested, decimal conversion is now performed on Py_UNICODE characters. For this purpose, I introduced _PyUnicode_NormalizeDecimal() function that takes Py_UNICODE and returns a PyUnicode object with whitespace stripped and non-ASCII digits converted to ASCII equivalents.  The PyUnicode_EncodeDecimal() function is no longer used and I added a comment recommending that _PyUnicode_NormalizeDecimal() be used instead. I would like to eventually remove PyUnicode_EncodeDecimal(), but I amd not sure about the proper deprecation procedures for undocumented C APIs.
> 
> As a result, int(), float(), etc will no longer raise UnicodeDecodeError unless given a string with lone surrogates.  (This error comes from UTF-8 codec that is applied after digit normalization.)
> 
> A few error cases such as embedded '\0' and non-digit characters with ord(c) > 255 will now raise ValueError instead of UnicodeDecodeError.  Since UnicodeDecodeError is a subclass of ValueError, it is unlikely that existing code would attempt to differentiate between the two.  It is possible to achieve complete compatibility, but it is hard to justify reporting different error types on non-digit characters below and above code point 255.
> 
> The patch contains tests for error messages that I tried to make robust by only requiring that s.strip() be found somewhere in the error message from int(s).  Note that since in this patch whitespace is stripped before the string is passed to the parser, the parser errors do not contain the whitespace.  This may actually be desirable because it helps the user to see the source of the error without being distracted by irrelevant white space.

Thanks for the patch. I've had a quick look...

Some comments:

 * Please change the API _PyUnicode_NormalizeDecimal() to
   PyUnicode_ConvertToASCIIDecimal() - that's closer to what
   it does.

 * Don't have the API remove any whitespace. It should just
   work on decimal digit code points (chainging the length
   of the Unicode string is a bad idea).

 * Please remove the note "This function is no longer used.
   Use _PyUnicode_NormalizeDecimal instead." from the
   PyUnicode_EncodeDecimal() API description in the
   header file. The API won't go away (it does have its
   use and is being used in 3rd party extensions) and
   you cannot guide people to use a Python private API.

 * Please double check the ref counts. I think you have a leak
   in PyLong_FromUnicode() (for norm) and possible in other
   functions as well.

----------

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

From report at bugs.python.org  Thu Dec  2 22:47:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 21:47:48 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291326468.7.0.59210455487.issue10528@psf.upfronthosting.co.za>


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

Georg, do I have to make a patch before beta1 for this to go in 3.2?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Dec  2 22:51:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 21:51:51 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1291326711.54.0.670193230031.issue8989@psf.upfronthosting.co.za>


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

Committed to py3k in r86936 with minor fixups.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 22:55:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Dec 2010 21:55:39 +0000
Subject: [issue10603] __file__ not usable, with certain paths on windows XP.
In-Reply-To: <1291288601.2.0.284782000328.issue10603@psf.upfronthosting.co.za>
Message-ID: <1291326939.73.0.739558763738.issue10603@psf.upfronthosting.co.za>


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

Great!

----------

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

From report at bugs.python.org  Thu Dec  2 23:01:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 02 Dec 2010 22:01:29 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291325608.02.0.923899265835.issue10562@psf.upfronthosting.co.za>
Message-ID: <4CF81737.8060508@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> In all seriousness, the idea of accepting both 'i' and 'j' in complex() isn't horrible. I'm personally -0.small on it, mostly because it seems likely to lead to more objections about the complex str() and repr() *output* containing 'j's.  I still think python-ideas would be a more appropriate place for that discussion, though.

I think this falls under a "locale" problem of some sort...
engineers like 'j', mathematician prefer 'i'.

Personally, I think it's more important to be able to read
scientific data easily without too many problems, then to be
able to write the processed data in exactly the same way it
was read.

When formatting complex numbers, you have the issues
of whether to include spaces, parens, 'i' or 'j', so this
is better left to a application space function to deal with,
IMHO.

I would prefer to have str() and repr() always use the
parens and j notation - it makes recognizing complex numbers
easier, e.g. compare

(1+0j)
>>> 0+1j
1j
>>> 11
11

to

(1+0j)
>>> 0+1j
(0+1j)
>>> 11
11

(but I guess that another problem)

----------

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

From report at bugs.python.org  Thu Dec  2 23:02:21 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Dec 2010 22:02:21 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291327341.49.0.365210151049.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Committed as r86937.  Thanks again for reviewing!  Although I do not anticipate any problems, I will keep an eye on the buildbots just in case.

Antoine, regarding "ms->alloced = (list_size + 1) / 2;", I ended up adding an extensive comment after all.

----------

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

From report at bugs.python.org  Thu Dec  2 23:02:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 22:02:55 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291327375.4.0.823478663841.issue10528@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That would be good.  While you could argue it's a bug, the fix is also slightly incompatible.

----------

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

From report at bugs.python.org  Thu Dec  2 23:03:10 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Dec 2010 22:03:10 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291327390.25.0.903377761891.issue9915@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
components: +Interpreter Core -Library (Lib)
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec  2 23:05:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 22:05:55 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291327555.3.0.468619587322.issue10197@psf.upfronthosting.co.za>


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

I think we should implement getstatusoutput and getoutput with Popen objects to gain portability and avoid spawning subshells.

----------

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

From report at bugs.python.org  Thu Dec  2 23:08:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 22:08:19 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291327699.21.0.727167397491.issue10562@psf.upfronthosting.co.za>


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

> Personally, I think it's more important to be able to read
> scientific data easily without too many problems, then to be
> able to write the processed data in exactly the same way it
> was read.

I wonder whether there are many examples where scientific data is written in a form that Python's complex() constructor couldn't currently read, but would be able to read if it accepted 'i' in place of 'j'.

My (wild) guess would be that, in the cases where the data isn't stored in binary form anyway, complex numbers are written simply as pairs of floats.

----------

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

From report at bugs.python.org  Thu Dec  2 23:08:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Dec 2010 22:08:26 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1291327390.31.0.950264929062.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291327702.3576.47.camel@localhost.localdomain>


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

Thank you!

----------

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

From report at bugs.python.org  Thu Dec  2 23:08:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 22:08:51 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <4CF810F1.8060004@egenix.com>
Message-ID: <AANLkTimx9h8SE2-DPSikyR7AJECuPmyJ1douXeRt0AqP@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> ?* Please change the API _PyUnicode_NormalizeDecimal() to
> ? PyUnicode_ConvertToASCIIDecimal() - that's closer to what
> ? it does.
>

Are you sure it is a good idea to give it a public name?  I have no
problem with calling it _PyUnicode_ConvertToASCIIDecimal().
("Transform" may be a better term, though.)

> ?* Don't have the API remove any whitespace. It should just
> ? work on decimal digit code points (chainging the length
> ? of the Unicode string is a bad idea).
>

Yes, that was a bad idea, but the old EncodeDecimal was replacing all
Unicode space with ASCII ' '.  It will be hard to replicate old
behavior without doing the same in  ConvertToASCIIDecimal().

> ?* Please remove the note "This function is no longer used.
> ? Use _PyUnicode_NormalizeDecimal instead." from the
> ? PyUnicode_EncodeDecimal() API description in the
> ? header file. The API won't go away (it does have its
> ? use and is being used in 3rd party extensions) and
> ? you cannot guide people to use a Python private API.
>

OK.  I had the same reservations about recommending private API.

> ?* Please double check the ref counts. I think you have a leak
> ? in PyLong_FromUnicode() (for norm) and possible in other
> ? functions as well.

Will do.  I should also add some more tests for error conditions.  I
test for leaks, but if the error branch is not covered, it is not
covered.

----------

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

From report at bugs.python.org  Thu Dec  2 23:15:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Dec 2010 22:15:48 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291328148.35.0.460761057427.issue10562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That would be a good question for a numpy/scipy-related mailing list, I guess.

----------

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

From report at bugs.python.org  Thu Dec  2 23:29:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 22:29:03 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291328943.07.0.817595644374.issue10562@psf.upfronthosting.co.za>


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

Maybe we need a complex analog to datetime.strptime:

  complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j

----------

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

From report at bugs.python.org  Thu Dec  2 23:31:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 02 Dec 2010 22:31:22 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>


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

The Python3 documentation for these numeric constructors is wrong.

Python has supported Unicode numerals specified as code points from the Unicode category "Nd" (decimal digit) since Python 1.6.0 when Unicode was first introduced in Python.

    http://www.unicode.org/versions/Unicode5.2.0/ch04.pdf
    (see Section 4.5: General Category)

The Python3 documentation adds a reference to the language spec which is not really ideal, since the language spec has different requirements than a number object constructor which has to deal with data input rather than program text:

    http://docs.python.org/dev/py3k/library/functions.html#float

The Python2 documentation does not have such an implication:

    http://docs.python.org/library/functions.html#float

The Python3 documentation needs to be extended to either mention that all Unicode code points from the Unicode category "Nd"  (decimal digit) are accepted as digits and used with their corresponding decimal digit value, or include a copy of the referenced language spec section with this definition of ''digit'':

digit := ::=  "0"..."9" and any Unicode code point with property "Nd"

Here's a complete list of the code point ranges that have this property:

   http://www.unicode.org/Public/5.2.0/ucd/extracted/DerivedNumericType.txt

(scroll to the end of the file)

It would also be worthwhile to add a note to the Python2 documentation.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 123136
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: Correct the float(), int() and complex() documentation
versions: Python 3.2

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

From report at bugs.python.org  Thu Dec  2 23:31:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 22:31:55 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291329115.92.0.483132631646.issue10610@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/issue10610>
_______________________________________

From report at bugs.python.org  Thu Dec  2 23:34:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Dec 2010 22:34:26 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291329266.24.0.080086362391.issue10610@psf.upfronthosting.co.za>


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

The reference to the language spec was really just a way to avoid spelling out all the details (again) about the precise form of a floating-point string;  apart from the accepted set of digits, the forms are exactly the same (optional sign, numeric part, optional exponent, ...);  spelling it all out twice gets a bit tiresome.

Would it be acceptable to add a note to the current documentation describing the alternative digits that are accepted?

----------

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

From report at bugs.python.org  Thu Dec  2 23:36:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 22:36:19 +0000
Subject: [issue1672568] silent error in email.message.Message.get_payload
Message-ID: <1291329379.03.0.880056265295.issue1672568@psf.upfronthosting.co.za>


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

I've taken another look at this, and the email module is pretty consistent about just passing through data if it can't interpret it according to standards.  I think it would lead to a cluttered API if we add support for being strict and raising errors piecemeal.  So I'm deferring this to 3.3 and the email6 work, where we plan to have a comprehensive 'strict' mode.

----------
keywords:  -easy, patch
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Thu Dec  2 23:41:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Dec 2010 22:41:00 +0000
Subject: [issue10602] Wrong assert* method in test_csv.test_register_kwargs
	masks error
In-Reply-To: <1291264737.89.0.524557953339.issue10602@psf.upfronthosting.co.za>
Message-ID: <1291329660.59.0.637782991467.issue10602@psf.upfronthosting.co.za>


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

Patch committed as r86940 (py3k), r86941 (3.1) and r86942 (2.7).

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

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

From report at bugs.python.org  Thu Dec  2 23:42:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 02 Dec 2010 22:42:16 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291328943.07.0.817595644374.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291329730.3576.48.camel@localhost.localdomain>


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

Le jeudi 02 d?cembre 2010 ? 22:29 +0000, Mark Dickinson a ?crit :
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Maybe we need a complex analog to datetime.strptime:
> 
>   complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j

How about '3 + 4i'.transform('complex')?

----------

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

From report at bugs.python.org  Thu Dec  2 23:47:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Dec 2010 22:47:57 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291330077.18.0.0653558340998.issue10197@psf.upfronthosting.co.za>


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

Do you have in implementation in mind?  I'm not clear how this would work.

----------

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

From report at bugs.python.org  Fri Dec  3 00:12:32 2010
From: report at bugs.python.org (Daniel Tavares)
Date: Thu, 02 Dec 2010 23:12:32 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291331552.56.0.706536587586.issue10367@psf.upfronthosting.co.za>


Daniel Tavares <danielmtavares at gmail.com> added the comment:

Here's an updated patch, which fixes the passing of multiple arguments to self.announce, based on Priscila's fix.

----------
nosy: +daniel.tavares
Added file: http://bugs.python.org/file19913/10367.diff

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

From report at bugs.python.org  Fri Dec  3 00:22:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Dec 2010 23:22:47 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291332167.94.0.567068059534.issue10610@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Dec  3 00:23:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 02 Dec 2010 23:23:14 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291332194.92.0.405884399866.issue10610@psf.upfronthosting.co.za>


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

Marc,

I don't want to further sprawl the python-dev thread, but it would be great if you could help with issue10587 as well.  That is a documentation-only issue, but there is some disagreement about how specific the docs should be.  Some of the relevant functions are documented in the header files, but some such as str.splitlines() are not.   I am posting it here because the level of detail that we want to document is probably similar in the two issues.  For example, we don't want to document things like int(3, -909) producing 3 in 2.6.  On the other hand, the fact that Arabic numerals are accepted by int() but Chinese are not, should probably be included.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Dec  3 00:32:04 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 02 Dec 2010 23:32:04 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <AANLkTimx9h8SE2-DPSikyR7AJECuPmyJ1douXeRt0AqP@mail.gmail.com>
Message-ID: <20101202233159.GA26436@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Alexander Belopolsky <report at bugs.python.org> wrote:
> On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
> > ?* Please change the API _PyUnicode_NormalizeDecimal() to
> > ? PyUnicode_ConvertToASCIIDecimal() - that's closer to what
> > ? it does.
> >
> 
> Are you sure it is a good idea to give it a public name?  I have no
> problem with calling it _PyUnicode_ConvertToASCIIDecimal().
> ("Transform" may be a better term, though.)

I like the public name. Extension authors can use it and be sure that
their programs accept exactly the same numeric strings as the rest of
Python.

Are you worried that the semantics might change? If they do, I would
actually welcome to have an official transformation function that
automatically follows the current preferences of python-dev (or the
Unicode Consortium).

----------

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

From report at bugs.python.org  Fri Dec  3 00:38:32 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Dec 2010 23:38:32 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1291333112.95.0.246237466707.issue9333@psf.upfronthosting.co.za>


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

So the presence of os.symlink depends on some dynamic privilege?

It seems to me that it's the first time in Python. For example, os.chroot() is always available on Unix, even when the user is not root.  Of course the call will fail at runtime.

Why not simply raise an exception when the user has not enough privileges? (I mean OSError or WindowsError of course, not AttributeError)

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

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

From report at bugs.python.org  Fri Dec  3 00:54:07 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 02 Dec 2010 23:54:07 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291329730.3576.48.camel@localhost.localdomain>
Message-ID: <AANLkTimSBNZmtWrN-rYc8q=X7cs80d2KyoGpymox9zrs@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

(7.8064-6j)

According to PEP 8, the output in our example should be with spaces
surrounding the subtraction operator, like this:
>>> (1 + 2.56j) * (-1 - 3.44j)
(7.8064 - 6j)

----------
Added file: http://bugs.python.org/file19914/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
<div>Why does the Python parser not follow PEP 8?</div><div>&gt;&gt;&gt; (1 + 2.56j) * (-1 - 3.44j)</div><div>(7.8064-6j)</div><div><br></div><div>According to PEP 8, the output in our example should be with spaces surrounding the subtraction operator, like this:</div>
<div><div>&gt;&gt;&gt; (1 + 2.56j) * (-1 - 3.44j)</div><div>(7.8064 - 6j)</div></div>

From report at bugs.python.org  Fri Dec  3 01:07:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 00:07:34 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <20101202233159.GA26436@yoda.bytereef.org>
Message-ID: <AANLkTinbsuHUUoO87HeCKds-csn=rrE-3qRKVtFKYy2k@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 6:32 PM, Stefan Krah <report at bugs.python.org> wrote:
..
> I like the public name. Extension authors can use it and be sure that
> their programs accept exactly the same numeric strings as the rest of
> Python.
>
> Are you worried that the semantics might change?

Yes, I am already working on a change that instead of stripping
whitespace will replace it with ASCI space.  I don't think that a
public TransformDecimalToASCII() function should care about space, but
in order to support current semantics without making an extra copy, I
need to do all replacements together.  (And of course I would not want
to publicly expose a function that modifies the string in-place.)

> If they do, I would
> actually welcome to have an official transformation function that
> automatically follows the current preferences of python-dev (or the
> Unicode Consortium).
>

I don't think either group has clearly articulated their preferences
with respect to such algorithm.

----------

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

From report at bugs.python.org  Fri Dec  3 01:16:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 00:16:50 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1291335410.04.0.617493678326.issue10609@psf.upfronthosting.co.za>


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

Isn?t s/iteritems/items/ enough?

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Dec  3 01:18:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 00:18:27 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1291335507.25.0.276190871211.issue10609@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec  3 01:31:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Dec 2010 00:31:59 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1291336319.51.0.652544301087.issue9333@psf.upfronthosting.co.za>


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

> So the presence of os.symlink depends on some dynamic privilege?

Yes.


> Why not simply raise an exception when the user has not enough
> privileges? (I mean OSError or WindowsError of course, not AttributeError)

My thinking was that anyone writing cross-platform code which uses symlink in any way is already doing hasattr(os, "symlink"), and if they get a symlink attribute, it should work. With an exception they would have to add an additional try/except for the common case that os.symlink would fail due to lack of privilege on Windows.

I suspect that most people are not running with the required privilege, as evidenced by a look around the web at how others have written and tested this area of code in their applications. Even if someone has an account with administrator-level access, the command prompt starts up with regular privileges, so even those users (e.g., myself) would experience os.symlink raising an exception. Until the application is started explicitly with administrator privileges by an account blessed with access to the symlink privilege does the os.symlink even provide value.

This was noticed in virtualenv3 right off the bat when the first os.symlink checkin happened (see msg112322). They do the hasattr check and go ahead expecting it to work, and it would not work in their case no matter what checks they would do. I've seen other applications setup to do the same thing.


In the end, I'd rather not make people do this:

if hasattr(os, "symlink"):
    if not os.path.exists(dest):
        try:
            os.symlink(src, dest)
        except OSError:
            print("no privilege")

but instead allow them to do what they are likely already be doing:            

if hasattr(os, "symlink"):
    if not os.path.exists(dest):
        os.symlink(src, dest)


For new uses of os.symlink on Windows versions which support it, it may appear a bit unorthodox. I accept that, and I wish it could "just work", but we're given a complex set of hoops to jump through in order to make this usable in any case. I made my decision based on the small percentage of times where this functionality is even available, coupled with existing usage of the function.

----------
stage: committed/rejected -> commit review
status: closed -> open

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

From report at bugs.python.org  Fri Dec  3 01:49:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 00:49:30 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291337370.48.0.205234486291.issue10197@psf.upfronthosting.co.za>


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

My idea is simply using Popen with appropriate args for stdout and stderr instead of using a shell command with redirections:

--- Lib/subprocess.py   (r?vision 86943)
+++ Lib/subprocess.py   (copie de travail)
@@ -560,11 +560,7 @@
     return ''.join(result)


-# Various tools for executing commands and looking at their output and status.
-#
-# NB This only works (and is only relevant) for UNIX.
-
-def getstatusoutput(cmd):
+def getstatusoutput(cmd, shell=True):
     """Return (status, output) of executing cmd in a shell.

     Execute the string 'cmd' in a shell with os.popen() and return a 2-tuple
@@ -581,14 +577,21 @@
     >>> subprocess.getstatusoutput('/bin/junk')
     (256, 'sh: /bin/junk: not found')
     """
-    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
-    text = pipe.read()
-    sts = pipe.close()
-    if sts is None: sts = 0
-    if text[-1:] == '\n': text = text[:-1]
+    # Wish I could use with...
+    popen = Popen(cmd, shell=shell, stdout=PIPE, stderr=STDOUT)
+    sts = popen.communicate() #or wait() or whatever is the right thing
+    try:
+        text = process.stdout.read()
+    finally:
+        process.stdout.close()
+    if sts is None:
+        sts = 0
+    if text.endswith('\n'):
+        text = text[:-1]
     return sts, text

(The new ?shell? argument is icing on the cake, allowing us to later support a list as cmd argument like Popen does.)

----------

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

From report at bugs.python.org  Fri Dec  3 01:54:00 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Dec 2010 00:54:00 +0000
Subject: [issue7911] unittest.TestCase.longMessage should default to True in
	Python 3.2
In-Reply-To: <1265915317.63.0.548370408241.issue7911@psf.upfronthosting.co.za>
Message-ID: <1291337640.92.0.223591337902.issue7911@psf.upfronthosting.co.za>


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

Committed revision 86944.

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

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

From report at bugs.python.org  Fri Dec  3 02:19:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Dec 2010 01:19:25 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291339165.13.0.875840842906.issue10534@psf.upfronthosting.co.za>


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

Here is a pretty minimal patch to expose bjunk and bpopular as attributes and document them along with b2j, which is already exposed but not documented.

I suppose the proposed paragraph could be formatted as a list, perhaps after 
   ":class:`SequenceMatcher` objects have the following methods:"
with 'methods' expanded to 'attributes and methods'. But I do not know how to do that and personally prefer what I wrote.

However, Georg, I am adding you as nosy so you can comment on the doc addition *before* I commit this tomorrow, to get it in the beta.

Still to do: improve the doctests, including those added as part of #2986, to use the exposed sets (they are already implicitly tested by the existing tests); deprecate the two obsolete function attributes, as discussed on pydev.

The docstrings and code comments might stand revision, and there is an XXX todo in the doc yet.

----------
keywords: +patch
nosy: +georg.brandl
stage: unit test needed -> commit review
Added file: http://bugs.python.org/file19915/difflib.10534.diff

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

From report at bugs.python.org  Fri Dec  3 02:25:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Dec 2010 01:25:19 +0000
Subject: [issue10611] sys.exit() in a test causes the run to stp
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>


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

Reported by a unittest2 user. 

A SystemExit (or GeneratorExit) will cause a test run to stop in 2.7 / 3.2. This would just be reported as an error in 2.6.

>>> from unittest import TestCase
>>> def test(s):
...  raise GeneratorExit
... 
>>> class T(TestCase):
...  test = test
... 
>>> t = T('test')
>>> t.run()


Above code works in Python 2.6 (the exception is caught by TestCase.run) but dies in 2.7 / 3.2

----------
assignee: michael.foord
keywords: easy
messages: 123153
nosy: michael.foord
priority: normal
severity: normal
stage: unit test needed
status: open
title: sys.exit() in a test causes the run to stp
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Dec  3 02:25:34 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Dec 2010 01:25:34 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1291339534.4.0.925248003031.issue10611@psf.upfronthosting.co.za>


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


----------
title: sys.exit() in a test causes the run to stp -> sys.exit() in a test causes a test run to die

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

From report at bugs.python.org  Fri Dec  3 02:34:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 01:34:17 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1291340057.94.0.70525107862.issue10611@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Dec  3 02:40:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 01:40:12 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1291340412.19.0.537996903976.issue7475@psf.upfronthosting.co.za>


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

I am probably a bit late to this discussion, but why these things should be called "codecs" and why should they share the registry with the encodings?  It looks like the proper term would be "transformations" or "transforms".

----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Dec  3 02:43:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Dec 2010 01:43:23 +0000
Subject: [issue10554] Context managerment support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291340603.87.0.229710609125.issue10554@psf.upfronthosting.co.za>


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

Here's a patch which implements the context manager and adds a few tests and a small doc change.

Tested on Mac and Windows.

----------
keywords: +patch
nosy: +brian.curtin
Added file: http://bugs.python.org/file19916/subprocess.diff

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

From report at bugs.python.org  Fri Dec  3 02:58:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 01:58:00 +0000
Subject: [issue10554] Context managerment support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291341480.13.0.96321256623.issue10554@psf.upfronthosting.co.za>


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

Thanks!  Patch looks good, tests pass and doc builds.

I have one question and two micro-nitpicks on http://codereview.appspot.com/3441041/

----------

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

From report at bugs.python.org  Fri Dec  3 02:58:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 01:58:53 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291341533.01.0.941609772667.issue10610@psf.upfronthosting.co.za>


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

Should we also review the documentation for fractions and decimals?  For example, fractions are documented as accepting "strings of decimal digits", but given that we have presumably non-identical str.isdigit() and str.isdecimal() methods, the above definition begs a question whether accepted strings should be digits, decimals or both?

----------

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

From report at bugs.python.org  Fri Dec  3 03:09:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Dec 2010 02:09:29 +0000
Subject: [issue10612] StopTestRun exception to halt test run
In-Reply-To: <1291342169.36.0.09336436937.issue10612@psf.upfronthosting.co.za>
Message-ID: <1291342169.36.0.09336436937.issue10612@psf.upfronthosting.co.za>


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

It is hard for test infrastructure to halt a test run unless it has access to the result object. 

A StopTestRun exception could be provided. This could be caught in TestCase.run and call TestResult.stop().

It could be parameterized so that StopTestRun(report=False) bombs out and stops the test run completely.

----------
assignee: michael.foord
components: Library (Lib)
messages: 123158
nosy: michael.foord
priority: normal
severity: normal
status: open
title: StopTestRun exception to halt test run
type: performance
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec  3 03:12:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Dec 2010 02:12:16 +0000
Subject: [issue10554] Context managerment support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291342336.38.0.55829558257.issue10554@psf.upfronthosting.co.za>


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

I updated the doc to be much more simple. I got used to sys.executable based tests :) New patch attached.

As for __del__, I think it should do it's thing, and the exit will do it's own. Context managers are traditionally used on file-based things, or things that can be opened or closed. Creating a Popen object will open one or more pipes, so we should just close those opened pipes.

----------
Added file: http://bugs.python.org/file19917/subprocess2.diff

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

From report at bugs.python.org  Fri Dec  3 03:21:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 02:21:23 +0000
Subject: [issue10554] Context managerment support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291342883.0.0.747277446837.issue10554@psf.upfronthosting.co.za>


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

New doc looks good. Suggested changes: make with a link, explaing why it?s a context manager.

-   Popen objects are supported as context managers via the ``with`` statement.
+   Popen objects are supported as context managers via the :keyword:`with`` statement, so that file descriptors are closed cleanly.

I agree with your view on __del__ vs. __exit__.

----------

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

From report at bugs.python.org  Fri Dec  3 03:23:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 02:23:08 +0000
Subject: [issue10554] Context managerment support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291342988.78.0.823333577359.issue10554@psf.upfronthosting.co.za>


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

:keyword:`with`` ? :keyword:`with`

----------

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

From report at bugs.python.org  Fri Dec  3 03:24:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 02:24:46 +0000
Subject: [issue10554] Context management support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291343086.83.0.517946678088.issue10554@psf.upfronthosting.co.za>


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


----------
title: Context managerment support for subprocess.Popen -> Context management support for subprocess.Popen

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

From report at bugs.python.org  Fri Dec  3 03:26:40 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 03 Dec 2010 02:26:40 +0000
Subject: [issue9299] os.makedirs(): Add a keyword argument to suppress "File
	exists" exception
In-Reply-To: <1279529255.89.0.917982060428.issue9299@psf.upfronthosting.co.za>
Message-ID: <1291343200.39.0.436060713442.issue9299@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Oh, yes, I missed that, too. I didn't pay attention to that. Thanks for  pointing out it and fix it!

----------

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

From report at bugs.python.org  Fri Dec  3 03:42:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 02:42:56 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1291344176.43.0.405252148409.issue2142@psf.upfronthosting.co.za>


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

To sum up the current consensus as I understand it, the missing end of line is clearly a bug, but the addition of ?\No newline at end of file? is controversial.  In the current patch, both are changed, so backporting only the first fix to 3.1 and 2.7 will require either agreeing to add ?\No newline etc? in those versions too, or make another patch for 3.1/2.7.

I uploaded the patch to http://codereview.appspot.com/3432041/ and made some minor comments.

----------
nosy: +benjamin.peterson, djc, eric.araujo, georg.brandl -BreamoreBoy

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

From report at bugs.python.org  Fri Dec  3 03:47:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Dec 2010 02:47:23 +0000
Subject: [issue10554] Context management support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291344443.7.0.527747128094.issue10554@psf.upfronthosting.co.za>


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

Committed in r86951. Thanks for the reviews!

----------
assignee:  -> brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Fri Dec  3 03:50:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 02:50:38 +0000
Subject: [issue10554] Context management support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1291344638.32.0.93390534704.issue10554@psf.upfronthosting.co.za>


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

?closing any open file descriptors on exit? is exactly the perfect wording I was looking for.  Thanks for the patch!

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

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

From report at bugs.python.org  Fri Dec  3 03:53:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 02:53:49 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291344829.29.0.413309910585.issue10557@psf.upfronthosting.co.za>


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

I am submitting a new patch that excludes int() changes.  The honest reason for the exclusion is that I gave up chasing a bug that only shows in full regrtest runs.  (Marc, I don't think it is related to what you thought was a missing norm decref: that place had result = NULL, not return NULL, so the contral was falling through to the decref after the if statement.)  Nevertheless, I think it makes sense to proceed with smaller steps.  As Marc suggested, PyUnicode_EncodeDecimal() API will stay indefinitely, so there is no urge to remove its use.  There are no actual bugs associated with int(), so technically it does not belong to this issue.

----------
Added file: http://bugs.python.org/file19918/issue10557c.diff

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

From report at bugs.python.org  Fri Dec  3 03:56:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 02:56:40 +0000
Subject: [issue8525] Display exception's subclasses in help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1291345000.26.0.283238546656.issue8525@psf.upfronthosting.co.za>


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

Didn?t the first message ask for the feature to be extended to non-exceptions classes?  ?Built-in? subclasses is a red herring, to me the feature is: display subclasses.  In the text output you can use the search feature of your pager to jump to a subclass, in the HTML output it would be a helpful link.

----------

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

From report at bugs.python.org  Fri Dec  3 04:00:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 03:00:07 +0000
Subject: [issue1058305] HTMLParser.locatestartagend regex too stringent
Message-ID: <1291345207.84.0.896711081596.issue1058305@psf.upfronthosting.co.za>


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

Closing this in favor of 1486713, which has a patch and covers additional issues.

----------
nosy:  -BreamoreBoy
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> HTMLParser : A auto-tolerant parsing mode

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

From report at bugs.python.org  Fri Dec  3 04:02:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 03:02:20 +0000
Subject: [issue8525] Display exception's subclasses in help()
In-Reply-To: <1291345000.26.0.283238546656.issue8525@psf.upfronthosting.co.za>
Message-ID: <AANLkTimFSXdjOZWLKThpV-04f3eB9NViK01guRTvZDR=@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 9:56 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Didn?t the first message ask for the feature to be extended to non-exceptions classes? ??Built-in?
> subclasses is a red herring, to me the feature is: display subclasses. ?In the text output you can use
> the search feature of your pager to jump to a subclass, in the HTML output it would be a helpful link.

If we don't restrict to builtins, then the display will depend on what
modules are currently loaded and will be useless for command line use
unless all subclasses are defined in the same module.

----------

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

From report at bugs.python.org  Fri Dec  3 04:06:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 03:06:34 +0000
Subject: [issue8525] Display exception's subclasses in help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1291345594.54.0.309388938165.issue8525@psf.upfronthosting.co.za>


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

Yes, I imagine the feature to be useful to find subclasses defined in the same module.  Rob, am I misunderstanding your original request?

----------

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

From report at bugs.python.org  Fri Dec  3 04:09:18 2010
From: report at bugs.python.org (Charles Harris)
Date: Fri, 03 Dec 2010 03:09:18 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>
Message-ID: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>


New submission from Charles Harris <charlesr.harris at gmail.com>:

The attached patch fixes the problem.

----------
components: Library (Lib)
files: gzip.patch
keywords: patch
messages: 123171
nosy: charris44
priority: normal
severity: normal
status: open
title: gzip._PaddedFile calls getattr with arguments in reversed order
versions: Python 3.2
Added file: http://bugs.python.org/file19919/gzip.patch

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

From report at bugs.python.org  Fri Dec  3 04:12:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 03:12:31 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>
Message-ID: <1291345951.53.0.417904436939.issue10613@psf.upfronthosting.co.za>


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

Thanks for the report and patch.  Can you add a test, to prevent a regression?

----------
nosy: +eric.araujo
stage:  -> unit test needed
type:  -> behavior
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Dec  3 04:37:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 03:37:41 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291347461.83.0.702619237196.issue10528@psf.upfronthosting.co.za>


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

The incompatibility worries me a bit.  A program compatible with Python 3.1 and 3.2 would have to support both sets of messages; I don?t know whether the i18n tools support having all the strings in one PO file, and how inconvenient it would be for translators.  I assume such transitions have happened in many projects and that people just accept the inconvenience.

Attached patch changes the strings to avoid warnings.  No tests added (I intend to write tests for i18n in argparse in the future, see #10497 and #10529).

Steven, I?d like your +1 before committing anything.  One message in particular is not very helpful, but I?ve been unable to find better placeholders (it?s in ArgumentPaser._get_value):
  msg = _('invalid %(name)s value: %(arg_string)r')

----------
keywords: +patch
Added file: http://bugs.python.org/file19920/fix-gettext-positionals.diff

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

From report at bugs.python.org  Fri Dec  3 05:10:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 04:10:58 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1291349458.97.0.717058771749.issue1486713@psf.upfronthosting.co.za>


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

I have committed a version of this patch, without the warnings, using the keyword 'strict=True' as the default, and with a couple added heuristics from other similar issues, in r86952.

kxroberto, if you want to supply your full name, I'll add you to Misc/ACKS.  Thanks for the original patch.

----------
nosy:  -BreamoreBoy
resolution:  -> accepted
stage: unit test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  3 05:14:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 04:14:17 +0000
Subject: [issue975556] HTMLParser lukewarm on bogus bare attribute chars
Message-ID: <1291349657.6.0.895778019559.issue975556@psf.upfronthosting.co.za>


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

The new strict=False mode from #1486713 handles this case.

----------
nosy: +r.david.murray
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
superseder:  -> HTMLParser : A auto-tolerant parsing mode

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

From report at bugs.python.org  Fri Dec  3 05:17:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 04:17:21 +0000
Subject: [issue1046092] HTMLParser fix to accept mailformed tag attributes
Message-ID: <1291349841.42.0.859703075561.issue1046092@psf.upfronthosting.co.za>


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

Included this in the 'strict=False' mode in the issue 1486713 patch.

----------
nosy: +r.david.murray -BreamoreBoy
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> HTMLParser : A auto-tolerant parsing mode

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

From report at bugs.python.org  Fri Dec  3 05:24:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 04:24:57 +0000
Subject: [issue1046092] HTMLParser fix to accept malformed tag attributes
Message-ID: <1291350297.82.0.349323752381.issue1046092@psf.upfronthosting.co.za>


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


----------
title: HTMLParser fix to accept mailformed tag attributes -> HTMLParser fix to accept malformed tag attributes

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

From report at bugs.python.org  Fri Dec  3 05:40:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 04:40:28 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1291351228.63.0.273773367955.issue10497@psf.upfronthosting.co.za>


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

I?ve started on a test but I?m not sure how to proceed, since I need to use or intercept gettext and compare the error messages of argparse with translated messages to prove that the gettext calls are bogus.  There are various ways of using or intercepting gettext from tests, but I have to experiment a bit before I can propose the simplest patch that could possibly work.

Exceptionally, I?d like to commit the change as is, and defer the testing for some months, until I can get to #10529.

----------
assignee:  -> eric.araujo

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

From report at bugs.python.org  Fri Dec  3 05:45:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 04:45:47 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1291351547.33.0.352129076222.issue9709@psf.upfronthosting.co.za>


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

Sounds like a ?+1 for the patch? to me :)

I get no warning on linux2 after the patch.  This is still a behavior change, and there might be code out there relying on self.get_export_symbols being called.  My understanding of extension modules build is too small for me to have confidence, so I will defer the decision to Tarek.

----------
assignee: eric.araujo -> tarek

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

From report at bugs.python.org  Fri Dec  3 05:46:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 04:46:43 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291351603.55.0.226213376896.issue10562@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19914/unnamed

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

From report at bugs.python.org  Fri Dec  3 05:49:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 04:49:32 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291351772.73.0.809456453063.issue10562@psf.upfronthosting.co.za>


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

Whether 1+2j is a literal or an expression is debatable.  I think +1 is an expression but 1+2j is a literal; neither should have a space.

I?m not sure the language reference and the actual implementation are in agreement here (I have peephole optimizations in mind).

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Dec  3 05:57:06 2010
From: report at bugs.python.org (Charles Harris)
Date: Fri, 03 Dec 2010 04:57:06 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345951.53.0.417904436939.issue10613@psf.upfronthosting.co.za>
Message-ID: <AANLkTim_mWZWWMT0ZRH+S7m-QkB9PZeFtoJ5=1S-CcAp@mail.gmail.com>


Charles Harris <charlesr.harris at gmail.com> added the comment:

Hi Eric,

On Thu, Dec 2, 2010 at 8:12 PM, ??ric Araujo <report at bugs.python.org> wrote:

Where are the guidelines for writing python tests?

Chuck

----------
Added file: http://bugs.python.org/file19921/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10613>
_______________________________________
-------------- next part --------------
Hi Eric,<br><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 8:12 PM, ??ric Araujo <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;">
<br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Thanks for the report and patch. ??Can you add a test, to prevent a regression?<br>
<br>
----------<br>
nosy: +eric.araujo<br>
stage: ??-&gt; unit test needed<br>
type: ??-&gt; behavior<br>
versions: +Python 2.7, Python 3.1<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>Where are the guidelines for writing python tests?<br><br>Chuck <br></div><br></div>

From report at bugs.python.org  Fri Dec  3 05:59:23 2010
From: report at bugs.python.org (Charles Harris)
Date: Fri, 03 Dec 2010 04:59:23 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>
Message-ID: <1291352363.36.0.586923060755.issue10613@psf.upfronthosting.co.za>


Changes by Charles Harris <charlesr.harris at gmail.com>:


Removed file: http://bugs.python.org/file19921/unnamed

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

From report at bugs.python.org  Fri Dec  3 06:06:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 05:06:04 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>
Message-ID: <1291352764.94.0.613925288311.issue10613@psf.upfronthosting.co.za>


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

The best way is to learn by imitation.  If you prefer to read, there is some guidance on http://www.python.org/dev/workflow/ and http://www.python.org/dev/faq/#how-to-test-a-patch .

Concretely, you need to open a file, wrap it in a _PaddedFile and check that attributes like name and closed are good (using assertEqual).

You?ll also want to follow patch guidelines at http://www.python.org/dev/patches/

----------

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

From report at bugs.python.org  Fri Dec  3 06:10:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Dec 2010 05:10:28 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291353028.46.0.500994178376.issue10610@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Try not to sprawl this all over the docs.  Find the most common root and document it there.  No need to garbage-up Fractions, Decimal etc. with something that is of zero interest to 99.9% of users.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Dec  3 06:19:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:19:53 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291353028.46.0.500994178376.issue10610@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=HALC_788L+4L3ZTJJ=b0giod=_a4eanJbnbG9@mail.gmail.com>


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

On Fri, Dec 3, 2010 at 12:10 AM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> Try not to sprawl this all over the docs. ?Find the most common root and document it there.
>?No need to garbage-up Fractions, Decimal etc. with something that is of zero interest to
> 99.9% of users.

Decimal do already has a big BNF display with

digit          ::=  '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

And a note that, btw, "Other Unicode decimal digits are also permitted
where digit appears above. These include decimal digits from various
other alphabets (for example, Arabic-Indic and Devan?gar? digits)
along with the fullwidth digits '\uff10' through '\uff19'."

http://docs.python.org/dev/library/decimal.html#decimal-objects

Builtin int() doc take you on a link chase that ends at the language
reference int literal BNF.   Bringing these all to a common root was
exactly the reason I brought up these related modules.

----------

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

From report at bugs.python.org  Fri Dec  3 06:23:29 2010
From: report at bugs.python.org (Charles Harris)
Date: Fri, 03 Dec 2010 05:23:29 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>
Message-ID: <1291353809.06.0.635568466305.issue10613@psf.upfronthosting.co.za>


Charles Harris <charlesr.harris at gmail.com> added the comment:

Looks like this was fixed by r86555 and a test added. I think you can close the ticket.

----------

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

From report at bugs.python.org  Fri Dec  3 06:25:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 05:25:45 +0000
Subject: [issue10613] gzip._PaddedFile calls getattr with arguments in
	reversed order
In-Reply-To: <1291345758.68.0.319851259177.issue10613@psf.upfronthosting.co.za>
Message-ID: <1291353945.7.0.875694686947.issue10613@psf.upfronthosting.co.za>


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

Good catch.  I?m tired, I should have noticed that :)

----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> gzip module calls getattr incorrectly

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

From report at bugs.python.org  Fri Dec  3 06:33:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:33:35 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291351772.73.0.809456453063.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTikD2OpdgSocFEq_j+qvbwFYcY_B7v5d4Ww4gLoT@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 11:49 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Whether 1+2j is a literal or an expression is debatable.
>?I think +1 is an expression but 1+2j is a literal; neither should have a space.

With respect to implementation there is no debate:

[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0,
0), line=''),
 TokenInfo(type=2 (NUMBER), string='1', start=(1, 0), end=(1, 1), line='1+1j'),
 TokenInfo(type=53 (OP), string='+', start=(1, 1), end=(1, 2), line='1+1j'),
 TokenInfo(type=2 (NUMBER), string='1j', start=(1, 2), end=(1, 4), line='1+1j'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0,
0), line=''),
 TokenInfo(type=53 (OP), string='-', start=(1, 0), end=(1, 1), line='-1'),
 TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='-1'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

(Who designed the tokenize interface, btw?  I took me 3 tries to come
up with the incantation above.)

>
> I?m not sure the language reference and the actual implementation are in agreement here
> (I have peephole optimizations in mind).

Literals are atomic to the tokenizer.  AST processes a stream of
tokens.  Peephole optimizations are irrelevant because these are hacks
that operate on the bytecode when the lexical structure is all but
forgotten.

----------

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

From report at bugs.python.org  Fri Dec  3 06:33:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:33:40 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291351772.73.0.809456453063.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Y9+6ts2kKYBTGt88V-6Zn=51ToLU7iM5dB2xd@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 11:49 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Whether 1+2j is a literal or an expression is debatable.
>?I think +1 is an expression but 1+2j is a literal; neither should have a space.

With respect to implementation there is no debate:

[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0,
0), line=''),
 TokenInfo(type=2 (NUMBER), string='1', start=(1, 0), end=(1, 1), line='1+1j'),
 TokenInfo(type=53 (OP), string='+', start=(1, 1), end=(1, 2), line='1+1j'),
 TokenInfo(type=2 (NUMBER), string='1j', start=(1, 2), end=(1, 4), line='1+1j'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0,
0), line=''),
 TokenInfo(type=53 (OP), string='-', start=(1, 0), end=(1, 1), line='-1'),
 TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='-1'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

(Who designed the tokenize interface, btw?  I took me 3 tries to come
up with the incantation above.)

>
> I?m not sure the language reference and the actual implementation are in agreement here
> (I have peephole optimizations in mind).

Literals are atomic to the tokenizer.  AST processes a stream of
tokens.  Peephole optimizations are irrelevant because these are hacks
that operate on the bytecode when the lexical structure is all but
forgotten.

----------

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

From report at bugs.python.org  Fri Dec  3 06:34:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:34:03 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291351772.73.0.809456453063.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Y9+6ts2kKYBTGt88V-6Zn=51ToLU7iM5dB2xd@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 11:49 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Whether 1+2j is a literal or an expression is debatable.
>?I think +1 is an expression but 1+2j is a literal; neither should have a space.

With respect to implementation there is no debate:

[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0,
0), line=''),
 TokenInfo(type=2 (NUMBER), string='1', start=(1, 0), end=(1, 1), line='1+1j'),
 TokenInfo(type=53 (OP), string='+', start=(1, 1), end=(1, 2), line='1+1j'),
 TokenInfo(type=2 (NUMBER), string='1j', start=(1, 2), end=(1, 4), line='1+1j'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

[TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0,
0), line=''),
 TokenInfo(type=53 (OP), string='-', start=(1, 0), end=(1, 1), line='-1'),
 TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2), line='-1'),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

(Who designed the tokenize interface, btw?  I took me 3 tries to come
up with the incantation above.)

>
> I?m not sure the language reference and the actual implementation are in agreement here
> (I have peephole optimizations in mind).

Literals are atomic to the tokenizer.  AST processes a stream of
tokens.  Peephole optimizations are irrelevant because these are hacks
that operate on the bytecode when the lexical structure is all but
forgotten.

----------

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

From report at bugs.python.org  Fri Dec  3 06:35:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:35:37 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291354537.32.0.676783498927.issue10562@psf.upfronthosting.co.za>


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

And of course, roundup ate my work.  The tokenize incantation was

>>> pprint(list(tokenize(iter([b'1+1j']).__next__)))

----------

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

From report at bugs.python.org  Fri Dec  3 06:36:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:36:26 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291354586.85.0.741210973699.issue10562@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg123186

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

From report at bugs.python.org  Fri Dec  3 06:37:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 05:37:08 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291354628.28.0.316037792556.issue10562@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg123187

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

From report at bugs.python.org  Fri Dec  3 06:41:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Dec 2010 05:41:34 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291354894.21.0.340662381533.issue10610@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Try not to twist yourself in a knot over this.

I'll be happy to review in proposed doc patch.

----------
assignee: docs at python -> rhettinger

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

From report at bugs.python.org  Fri Dec  3 07:07:17 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 03 Dec 2010 06:07:17 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1291356437.05.0.523461393468.issue10609@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Eric,
on and up-to-date py3k I got this:


>>> for k, v in db.items():
...     print(k, '\t', v)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '_dbm.dbm' object has no attribute 'items'
>>> 'items' in dir(db)
False

(I tried to use items() before proposing that code ;)).

----------

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

From report at bugs.python.org  Fri Dec  3 07:33:37 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 03 Dec 2010 06:33:37 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291053095.5.0.677648990799.issue10577@psf.upfronthosting.co.za>
Message-ID: <20101203063324.GA2919@rubuntu>


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

On Mon, Nov 29, 2010 at 05:51:35PM +0000, Antoine Pitrou wrote:

> However, urllib.request.urlopen() works fine in this case, so
> perhaps this advocates for deprecating the old stuff? Senthil?

Yes. It should be deprecated.. I created a branch for trying
removing/refactoring some old old (urlretrive, etc) for eg. Let me go
along that and come up with something soon.

----------

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

From report at bugs.python.org  Fri Dec  3 07:46:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 06:46:04 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291358764.31.0.230130624352.issue10367@psf.upfronthosting.co.za>


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

Thanks Daniel.  I have good and bad news for this patch.

The bad news is that I don?t want to accept patches without tests.  We need to stop guessing or experimenting with the real PyPI to fix bugs.

The good news is that we have a mock PyPI server in distutils2.  Its use is described at http://distutils2.notmyidea.org/library/distutils2.tests.pypi_server.html and there are examples in the current test suite.  Instructions for patching distutils2 are at http://wiki.python.org/moin/Distutils/FixingBugs .  When a patch that includes a test is written, I will backport the relevant parts to distutils1.

----------
assignee:  -> eric.araujo
components: +Distutils, Distutils2
nosy: +tarek
versions: +3rd party, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec  3 07:47:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 06:47:15 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291358835.81.0.561971850334.issue10453@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
priority: normal -> high
stage: needs patch -> unit test needed

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

From report at bugs.python.org  Fri Dec  3 08:07:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 07:07:50 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291360070.85.0.132923390162.issue10534@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Don't worry about doc additions too much; all doc changes can be considered bug fixes.

In this patch, it appears that two of the three attributes are new?  They should get a versionadded.

----------

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

From report at bugs.python.org  Fri Dec  3 08:32:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Dec 2010 07:32:32 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291361552.64.0.639496764348.issue10610@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg123190

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

From report at bugs.python.org  Fri Dec  3 08:38:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 07:38:37 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1291361917.12.0.91531077875.issue1745035@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r86955.  Thanks!

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

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

From report at bugs.python.org  Fri Dec  3 08:39:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Dec 2010 07:39:32 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291329082.54.0.0152970985117.issue10610@psf.upfronthosting.co.za>
Message-ID: <1291361972.36.0.638397332346.issue10610@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Let me know when you have a proposed doc patch.  Ideally, the details should just be in one place and we can refer to it elsewhere.   We don't want to add extra info to every function or method in Python that uses int(s) and gets extra unicode digits as an unintended artifact.

----------

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

From report at bugs.python.org  Fri Dec  3 08:42:01 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 03 Dec 2010 07:42:01 +0000
Subject: [issue10614] ZipFile and CP932 encoding
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>


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

Currently, ZipFile only accepts ascii or utf8 as file
name encodings. On Windows (Japanese), usually CP932
is used for it. So currently, when we melt ZipFile
via py3k, non-ascii file name becomes strange. Can we handle
this issue? (ie: adding encoding option for ZipFile#__init__)

----------
components: Extension Modules
messages: 123197
nosy: ocean-city
priority: normal
severity: normal
status: open
title: ZipFile and CP932 encoding
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec  3 08:47:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 07:47:30 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1291362450.74.0.994543435304.issue940286@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good; committed in r86957.

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

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

From report at bugs.python.org  Fri Dec  3 08:56:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 07:56:49 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1291363009.54.0.787781748972.issue10360@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree; committed in r86960.

If anyone wants to change this to raise TypeError for objects that are both unhashable and unrefable, please speak up.

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

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

From report at bugs.python.org  Fri Dec  3 09:00:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 08:00:50 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291363250.73.0.643619711906.issue10562@psf.upfronthosting.co.za>


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

> Whether 1+2j is a literal or an expression is debatable.

Really?  I can't imagine what basis you'd have for calling either 1+2j or +1 a literal.

----------

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

From report at bugs.python.org  Fri Dec  3 09:07:40 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 03 Dec 2010 08:07:40 +0000
Subject: [issue10614] ZipFile and CP932 encoding
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1291363660.14.0.549881643078.issue10614@psf.upfronthosting.co.za>


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

The ZIP format specification mentions only cp437 and utf8: http://www.pkware.com/documents/casestudies/APPNOTE.TXT see Apeendix D.
Do zip files created on Japanese Windows contain some information about the encoding they use?
Or do some programs write cp932 where they are supposed to use one of the encodings above?

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

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

From report at bugs.python.org  Fri Dec  3 09:13:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Dec 2010 08:13:31 +0000
Subject: [issue10614] ZipFile and CP932 encoding
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1291364011.43.0.784033647356.issue10614@psf.upfronthosting.co.za>


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

No, there is no indication in the zipfile that it deviates from the spec. That doesn't stop people from creating such zipfiles, anyway; many zip tools ignore the spec and use instead CP_ACP (which, of course, will then get misinterpreted if extracted on a different system).

I think we must support this case somehow, but must be careful to avoid creating such files unless explicitly requested. One approach might be to have two encodings given: one to interpret the existing filenames, and one to be used for new filenames (with a recommendation to never use that parameter since zip now supports UTF-8 in a well-defined manner).

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

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

From report at bugs.python.org  Fri Dec  3 09:21:38 2010
From: report at bugs.python.org (William Barr)
Date: Fri, 03 Dec 2010 08:21:38 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1291364498.78.0.487915022557.issue10365@psf.upfronthosting.co.za>


William Barr <webmaster961 at gmail.com> added the comment:

Ok, attached is a patch that should make IDLE silently ignore this happening; upon looking into this, it was a rather trivial fix.  The open function was waiting on the return input from the askopenfile call, during which the calling window was closed, setting the editwin parameter to None according to close.  The patch just adds another try/except to catch the AttributeError raised when the non-extant editwin's flist is referenced.  

I did come up with a method to actually make it continue with the opening process (just save a copy of the editwin's flist before the askopenfile call, during which the editwin gets closed), but that seemed a bit kludgey and possibly dangerous;, however it *seems* to work without issue.  I can upload that patch as well if anyone would care to review it in addition to the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file19922/issue10365.patch

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

From report at bugs.python.org  Fri Dec  3 09:36:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 08:36:34 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1291365394.1.0.883798830291.issue3132@psf.upfronthosting.co.za>


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

> For reference, Numpy's PEP 3118 implementation is here:

Thanks for that, and the other information you give;  that's helpful.

It sounds like we're on the same page with respect to alignment of substructs.  (Bar the mostly academic question of max versus lcm.)

I still like the idea of scoped endianness markers in the substructs, but  if we have to abandon that for compatibility with NumPy that's okay.

- I assumed the 'O' format in the PEP is supposed to be similar to Numpy
  object arrays. This implies some reference counting semantics. The
  Numpy PEP 3118 implementation assumes the memory contains borrowed
  references, valid at least until the buffer is released.
  Unpacking 'O' should probably INCREF whatever PyObject* pointer is
  there.

I'm still confused about how this could work:  when unpacking, how do you know whether the PyObject* pointer points to a valid object or not?  You can ensure that the pointer will always point to a valid object by having the *pack* operation increment reference counts, but then you need a way to automatically decref when the packed string goes out of scope.  So the object returned by 'pack' would somehow have to be something other than a plain string, so that it can deal with automatically doing the DECREF of the held PyObject* pointers when it goes out of scope.

What's the need to have the 'O' format in the struct module?  Is it really necessary there?  Can we get away with not implementing it?

----------

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

From report at bugs.python.org  Fri Dec  3 09:38:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 08:38:55 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1291365535.95.0.109892277653.issue3132@psf.upfronthosting.co.za>


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

> For reference, Numpy's PEP 3118 implementation is here

BTW, does this already exist in a released version of NumPy?  If not, when is it likely to appear in the wild?

----------

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

From report at bugs.python.org  Fri Dec  3 09:46:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 03 Dec 2010 08:46:30 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1291340412.19.0.537996903976.issue7475@psf.upfronthosting.co.za>
Message-ID: <4CF8AE63.8090607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I am probably a bit late to this discussion, but why these things should be called "codecs" and why should they share the registry with the encodings?  It looks like the proper term would be "transformations" or "transforms".

.transform() is just the name of the method. The codecs are still just
that: codecs, i.e. objects that encode and decode data. The types they
support are defined by the codecs, not by the helper methods.

In Python3, the str and bytes methods .encode() and .decode() will
only support str->bytes->str conversions. The new
str and bytes .transform() method adds back str->str and
bytes->bytes.

The codec subsystem does not impose restrictions on the type combinations
a codec can support, and that's per design.

----------

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

From report at bugs.python.org  Fri Dec  3 09:49:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Dec 2010 08:49:24 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1291366164.12.0.847896799336.issue10365@psf.upfronthosting.co.za>


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

The indentation of the patch 'looks' wrong. That appears to be because you used tabs instead of spaces (as in the lines removed and I presume elsewhere in the file -- and because FireFox interprets tabs as 8 spaces. Please redo with spaces. I will try to look at it during 3.2 beta phase if no one beats me to it.

----------

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

From report at bugs.python.org  Fri Dec  3 09:53:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 08:53:19 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291366399.02.0.0133889136294.issue10562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

An imaginary basis maybe?

----------

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

From report at bugs.python.org  Fri Dec  3 10:14:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 03 Dec 2010 09:14:07 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291341533.01.0.941609772667.issue10610@psf.upfronthosting.co.za>
Message-ID: <4CF8B4DA.9030700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> Should we also review the documentation for fractions and decimals?  For example, fractions are documented as accepting "strings of decimal digits", but given that we have presumably non-identical str.isdigit() and str.isdecimal() methods, the above definition begs a question whether accepted strings should be digits, decimals or both?

The term "decimal digit" is defined in the Unicode standard as those code
points having the category "Ld". See
http://www.unicode.org/versions/Unicode5.2.0/ch04.pdf

The methods .isdecimal(), .isdigit() and .isnumeric() check the
availability the resp. field entries 6, 7 and 8 in the UCD

See http://www.unicode.org/reports/tr44/#Numeric_Type for details
and http://www.unicode.org/Public/6.0.0/ucd/extracted/DerivedNumericType.txt
for the full list of code points with these fields set.

The docs for those methods need to be updated as well. Doing this
for .isdigit() and .isnumeric() is a bit difficult, though, since
the code points don't fall into just a single category.

The best option is to refer to the code point properties
Numeric_Type=Decimal for .isdecimal(), Numeric_Type=Digit
for .isdigit() and Numeric_Type=Numeric for .isnumeric().

The resp. numeric values are available via the unicodedata module.

----------

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

From report at bugs.python.org  Fri Dec  3 10:18:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 03 Dec 2010 09:18:20 +0000
Subject: [issue10610] Correct the float(), int() and complex() documentation
In-Reply-To: <1291353028.46.0.500994178376.issue10610@psf.upfronthosting.co.za>
Message-ID: <4CF8B5D9.8050903@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Raymond Hettinger wrote:
> 
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
> Try not to sprawl this all over the docs.  Find the most common root and document it there.  No need to garbage-up Fractions, Decimal etc. with something that is of zero interest to 99.9% of users.

That's a good idea. It may be enough to just add a new

unicode_decimal_digit ::= ...

to the language spec (even if it is not used there) and then reference
it from the other parts of the docs.

Same for unicode_digit and unicode_numeric.

----------

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

From report at bugs.python.org  Fri Dec  3 10:22:38 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 03 Dec 2010 09:22:38 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291368158.8.0.930984329341.issue10528@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

If I understand it right, before this patch, people couldn't really supply internationalizations for these calls - they would have had to have a translation for each possible value of, e.g. action.choices or parser.prefix_chars. So I think there's pretty minimal danger of breaking that code.

Specific comments on names in the patch:

* rename %(character) to %(prefix_chars)
* rename %(name) to %(type) and %(arg_string) to %(value)
* rename %(program_name) to %(prog)

Basically, we should use the name of an Action or ArgumentParser attribute whenever it makes sense. Hopefully that will make it more intuitive what these mean when people are translating them.

And yes, with the above changes, +1.

----------

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

From report at bugs.python.org  Fri Dec  3 10:26:06 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 03 Dec 2010 09:26:06 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291366399.02.0.0133889136294.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTin+Nkr-c7QuHx1HDGmkWHNp1hh6w1gSjjh26WPq@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

The result of 1 + 2j cannot be further broken down, so the result stays as 1
+ 2j (note the spaces!).

(1+2j)

(1 + 2j)

Following PEP 8 in this regard is also needed. Abandon the request of adding
the i unit and rather fix this spacing issue. The complex() built-in
function should also be fixed to add spaces around operators.

----------
Added file: http://bugs.python.org/file19923/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
The result of 1 + 2j cannot be further broken down, so the result stays as 1 + 2j (note the spaces!).<div><br></div><div>No:</div><div><div>&gt;&gt;&gt; 1 + 2j</div><div>(1+2j)</div></div><div><br></div><div>Yes:</div><div>
<div>&gt;&gt;&gt; 1 + 2j</div><div>(1 + 2j)</div></div><div><br></div><div><br></div><div>Following PEP 8 in this regard is also needed. Abandon the request of adding the i unit and rather fix this spacing issue. The complex() built-in function should also be fixed to add spaces around operators.</div>

From report at bugs.python.org  Fri Dec  3 10:26:15 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 03 Dec 2010 09:26:15 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291368375.42.0.888993562514.issue10528@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Hmm. I see I confused this with Issue 10529, where there really was a bug in the gettext calls. Nonetheless, +1 for switching from %s to %(xxx)s in 3.2 - since that's the first release in Python 3 that has argparse, I think it's really okay to do this.

----------

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

From report at bugs.python.org  Fri Dec  3 10:30:50 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 03 Dec 2010 09:30:50 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1291368650.21.0.937862093172.issue10497@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yes, I think it's okay to fix this without a test, given that it's a nontrivial amount of work to test gettext stuff. I'd rather have it working now, without tests, than wait until we know how to test stuff with gettext.

It's also a pretty minor, obvious fix. Of course, I assume you'll make sure this also merges correctly with your Issue 10528 patch.

----------

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

From report at bugs.python.org  Fri Dec  3 10:33:29 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 09:33:29 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291368809.6.0.298428003448.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed in r86962.

Thanks to all involved in getting this from initial submission to final checkin :)

Any further changes (including addressing ?ric's last few comments) can be undertaken as separate issues.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  3 10:34:45 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 09:34:45 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291368885.51.0.901061540191.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, I also fixed in issue in both the old and new server code that switched warnings off globally rather than merely for the operation it was trying to disable warnings for.

----------

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

From report at bugs.python.org  Fri Dec  3 10:35:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 03 Dec 2010 09:35:32 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291328943.07.0.817595644374.issue10562@psf.upfronthosting.co.za>
Message-ID: <4CF8B9E1.1040509@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Maybe we need a complex analog to datetime.strptime:
> 
>   complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j

That's a good idea.

Perhaps we could also add a .strfcx() to do the formatting in much
the same way.

----------

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

From report at bugs.python.org  Fri Dec  3 10:45:03 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 03 Dec 2010 09:45:03 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <AANLkTimx9h8SE2-DPSikyR7AJECuPmyJ1douXeRt0AqP@mail.gmail.com>
Message-ID: <4CF8BC1C.8070803@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>>  * Please change the API _PyUnicode_NormalizeDecimal() to
>>   PyUnicode_ConvertToASCIIDecimal() - that's closer to what
>>   it does.
>>
> 
> Are you sure it is a good idea to give it a public name?  I have no
> problem with calling it _PyUnicode_ConvertToASCIIDecimal().
> ("Transform" may be a better term, though.)

Yes, I think it's useful to have as public API.

>>  * Don't have the API remove any whitespace. It should just
>>   work on decimal digit code points (chainging the length
>>   of the Unicode string is a bad idea).
>>
> 
> Yes, that was a bad idea, but the old EncodeDecimal was replacing all
> Unicode space with ASCII ' '.  It will be hard to replicate old
> behavior without doing the same in  ConvertToASCIIDecimal().

Are you sure ? I'm not sure how the underlying PyOS_string_to_double()
(IIRC) works. If it needs ASCII spaces, it's probably OK to just do
the replacement in the constructors. This may have a side-effect
on error reporting, though, e.g. if you convert TABs to single
spaces, the error message will use different formatting than
the original string.

>>  * Please remove the note "This function is no longer used.
>>   Use _PyUnicode_NormalizeDecimal instead." from the
>>   PyUnicode_EncodeDecimal() API description in the
>>   header file. The API won't go away (it does have its
>>   use and is being used in 3rd party extensions) and
>>   you cannot guide people to use a Python private API.
>>
> 
> OK.  I had the same reservations about recommending private API.
> 
>>  * Please double check the ref counts. I think you have a leak
>>   in PyLong_FromUnicode() (for norm) and possible in other
>>   functions as well.
> 
> Will do.  I should also add some more tests for error conditions.  I
> test for leaks, but if the error branch is not covered, it is not
> covered.

Thanks. Error branches often introduce such leaks; which is why
I got used to having an onError: goto target in functions which
then do Py_XDECREF() on all temporary variables I need in the
function.

----------

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

From report at bugs.python.org  Fri Dec  3 10:45:53 2010
From: report at bugs.python.org (Robert Lehmann)
Date: Fri, 03 Dec 2010 09:45:53 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291369553.31.0.287534413433.issue10562@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

> I wonder whether there are many examples where scientific data is written in a form that Python's complex() constructor couldn't currently read, but would be able to read if it accepted 'i' in place of 'j'.

I could not reproduce widespread real world issues with the syntax as it stands using Google Code Search (a mere 4 unique hits). http://goo.gl/sqMhY

----------
nosy: +lehmannro

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

From report at bugs.python.org  Fri Dec  3 10:57:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 09:57:35 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291370255.09.0.529167154871.issue10557@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/issue10557>
_______________________________________

From report at bugs.python.org  Fri Dec  3 10:59:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 09:59:06 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291370346.79.0.898531655547.issue10562@psf.upfronthosting.co.za>


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

Thanks for that, Robert.

Actually, I find those few results quite convincing as evidence that it would be useful to support 'i' (and 'I') on input.

----------

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

From report at bugs.python.org  Fri Dec  3 10:59:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 09:59:48 +0000
Subject: [issue10549] help(cls1) breaks when cls1 has staticmethod(cls2)
	attribute
In-Reply-To: <1290875872.01.0.0960712603698.issue10549@psf.upfronthosting.co.za>
Message-ID: <1291370388.54.0.797661041746.issue10549@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r86964.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Dec  3 11:02:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 10:02:34 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291370554.32.0.849337564266.issue10557@psf.upfronthosting.co.za>


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

> Are you sure ? I'm not sure how the underlying PyOS_string_to_double()
> (IIRC) works.

I believe it accepts ASCII whitespace (i.e., chars ' ', '\t', '\f', '\n', '\r', '\v'), and nothing else.

----------

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

From report at bugs.python.org  Fri Dec  3 11:02:53 2010
From: report at bugs.python.org (Adrian von Bidder)
Date: Fri, 03 Dec 2010 10:02:53 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1291326711.54.0.670193230031.issue8989@psf.upfronthosting.co.za>
Message-ID: <201012031102.48055@fortytwo.ch>


Adrian von Bidder <avbidder at fortytwo.ch> added the comment:

On Thursday 02 December 2010 22.51:51 you wrote:

> Committed to py3k in r86936 with minor fixups.

thanks, great!  (Wheee! my first patch to Python ;-)

cheers
-- vbi

----------

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

From report at bugs.python.org  Fri Dec  3 11:06:59 2010
From: report at bugs.python.org (Robert Lehmann)
Date: Fri, 03 Dec 2010 10:06:59 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291370819.58.0.854729345829.issue10576@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

A few issues I'd like to raise:

(1) Multiple callback chains.  Is there any code in your existing use case of GC callbacks where you don't check for the phase argument and follow different code paths depending on it?  If not, having two callback chains should be fine and takes the burden from the programmer to the implementors.  (This is feasible if we *only ever* have two values for the phase.)

(2) Single collections.  Currently, neither PyGC_Collect nor gc.collect() invoke the callbacks (since they do not call collect_generations).  Is this an oversight or intentional?

(3) Error checking.  What about callbacks which are bound to fail on each and every invocation, ie. because of wrong signatures.  Should these be flat-out rejected in some way *on registration*, automagically removed when first encountered, or are we okay with errors slammed into the user's face every so often because he should REALLY fix them?

(4) Interop.  Can this be supported as easily on other VMs?  (That's perhaps a good reason for the statistics to be a dict, for GCs providing vastly different amounts of information.)

----------
nosy: +lehmannro

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

From report at bugs.python.org  Fri Dec  3 11:13:53 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 03 Dec 2010 10:13:53 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291371233.79.0.0642315890894.issue10576@psf.upfronthosting.co.za>


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

1) I'm not sure what you are asking.  Does anyone think that it is simpler to register two different callbacks than one?  IMHO it complicates the interface and creates so many oppertunities to do things incorrectly.

2)No, it is an oversight, let me verify the code.

3)I don't think we ought to be smart and try to remove callbacks.  I don't think that is common practice, the developer will know soon enough if things don't work.  Just keep it simple.

4)Interop, I think, is not an issue.  the gc module is a C-Python only implementation detail.  Every implementation has the freedom to collect garbage in its own way.

I'll post an updated version soon.

----------

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

From report at bugs.python.org  Fri Dec  3 11:33:48 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Fri, 03 Dec 2010 10:33:48 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1291372428.42.0.188968957379.issue3132@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

> I still like the idea of scoped endianness markers in the substructs,
> but  if we have to abandon that for compatibility with NumPy that's
> okay.

That, or change the Numpy implementation. I don't believe there's yet much code in the wild that changes the alignment specifier on the fly.

[clip: 'O' format code]
> So the object returned by 'pack' would somehow
> have to be something other than a plain string, so that it can deal
> with automatically doing the DECREF of the held PyObject* pointers
> when it goes out of scope.

Yes, the packed object would need to own the references, and it would be the responsibility of the provider of the buffer to ensure that the pointers are valid.

It seems that it's not possible for the `struct` module to correctly implement packing for the 'O' format. Unpacking could be possible, though (but then if you don't have packing, how write tests for it?).

Another possibility is to implement the 'O' format unsafely and leave managing the reference counting to whoever uses the `struct` module's capabilities. (And maybe return ctypes pointers on unpacking.)

[clip]
> What's the need to have the 'O' format in the struct module?  Is it
> really necessary there?  Can we get away with not implementing it?

Numpy arrays, when containing Python objects, function as per the 'O' format.

However, for the struct module, I don't see what would be the use case for the 'O' format.

> BTW, does this already exist in a released version of NumPy?  If not,
> when is it likely to appear in the wild?

It's included since the 1.5.0 release which came out last July.

    ***

I think after the implementation is done, the PEP probably needs to be amended with clarifications (and possibly cutting out what is not really needed).

----------

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

From report at bugs.python.org  Fri Dec  3 12:12:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 11:12:24 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291374744.42.0.987141551379.issue2001@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The html_getfile() function is Unix-specific: it constructs paths like

path = os.sep + path.replace('%20', ' ')

Consequently, its test fails on Windows:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/3703/steps/test/logs/stdio

----------
keywords: +buildbot -patch
status: closed -> open

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

From report at bugs.python.org  Fri Dec  3 12:27:31 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 03 Dec 2010 11:27:31 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291375651.16.0.231780278423.issue2001@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/issue2001>
_______________________________________

From report at bugs.python.org  Fri Dec  3 12:54:27 2010
From: report at bugs.python.org (Rob Cliffe)
Date: Fri, 03 Dec 2010 11:54:27 +0000
Subject: [issue8525] Display exception's subclasses in help()
In-Reply-To: <1291345594.54.0.309388938165.issue8525@psf.upfronthosting.co.za>
Message-ID: <4CF8DA64.5080303@btinternet.com>


Rob Cliffe <rob.cliffe at btinternet.com> added the comment:

Originally I only had built-in classes in mind (with Exceptions being 
IMO the most obvious example of a built-in class hierarchy that it is 
useful to find your way around).  But if the idea can be extended to 
other classes, well, great.
Rob Cliffe

----------

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

From report at bugs.python.org  Fri Dec  3 13:12:33 2010
From: report at bugs.python.org (Steven Youngs)
Date: Fri, 03 Dec 2010 12:12:33 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1291378353.86.0.695246167934.issue10363@psf.upfronthosting.co.za>


Changes by Steven Youngs <steve at youngs.cc>:


----------
nosy: +StevenY

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

From report at bugs.python.org  Fri Dec  3 13:27:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 12:27:17 +0000
Subject: [issue10614] ZipFile and CP932 encoding
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1291379237.81.0.622042718666.issue10614@psf.upfronthosting.co.za>


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

@Hirokazu: Can you attach a small test archive?

Yes, we can add a "default_encoding" attribute to ZipFile and add an optional default_encoding argument to its constructor.

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Dec  3 13:28:33 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 03 Dec 2010 12:28:33 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291379313.08.0.302123785674.issue10557@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

According to comments in the code and verified by inspection, PyOS_string_to_double does not accept any whitespace.

----------

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

From report at bugs.python.org  Fri Dec  3 13:30:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 12:30:06 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291379406.78.0.454266753023.issue2001@psf.upfronthosting.co.za>


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

Nick, you seem to have forgotten to svn add the CSS file.

----------

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

From report at bugs.python.org  Fri Dec  3 13:35:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 12:35:36 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291379736.12.0.603595530618.issue10197@psf.upfronthosting.co.za>


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

-def getstatusoutput(cmd):
+def getstatusoutput(cmd, shell=True):

shell=True is dangerous, it can lead to shell command injection. I would prefer to set its default value to False. The function already exists in Python 3.1, but it is not used in Python source code. Is it too late to fix its API to avoid security vulnerabilities?

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Dec  3 13:35:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 12:35:55 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1291379755.33.0.019625196063.issue10497@psf.upfronthosting.co.za>


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

>From the other bug: ?If I understand it right, before this patch, people couldn't really supply internationalizations for these calls - they would have had to have a translation for each possible value of, e.g. action.choices or parser.prefix_chars.?  Exactly.

I will commit this evening and refresh the other patch (there is one overlapping change).

----------
priority: normal -> high
status: open -> pending

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

From report at bugs.python.org  Fri Dec  3 13:43:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 12:43:36 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291380216.34.0.648981943596.issue10528@psf.upfronthosting.co.za>


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

This bug is a warning, not a fatal error: ?The translator cannot reorder the arguments.?  Depending on the language, it may be a real pain.

?Basically, we should use the name of an Action or ArgumentParser attribute whenever it makes sense. Hopefully that will make it more intuitive what these mean when people are translating them.?  Exactly.  That?s why I suggested %(program_name) instead of %(prog); keep in mind translators are not necessarily programmers, so the familiar argparse terms may not make sense to them.

If Georg is okay with the lack of tests (apart manual testing showing that xgettext does not print warnings anymore), I will apply your changes and commit this tonight, which should be in time for beta1.

----------
dependencies: +Incorrect use of gettext in argparse
priority: normal -> high
stage: needs patch -> commit review
status: open -> pending

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

From report at bugs.python.org  Fri Dec  3 13:45:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 12:45:34 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291380334.12.0.671795952822.issue10562@psf.upfronthosting.co.za>


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

> I can't imagine what basis you'd have for calling either 1+2j or +1 a literal.

Poor understanding of the parser/tokenizer/formal grammar.

----------

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

From report at bugs.python.org  Fri Dec  3 13:46:02 2010
From: report at bugs.python.org (Johann Hanne)
Date: Fri, 03 Dec 2010 12:46:02 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>


New submission from Johann Hanne <python at jf.hanne.name>:

Some C files fail to compile with mingw, mostly due to missing preprocessor statements:
- Modules/_ctypes/callproc.c
When using the bundled non-msvc libffi, ffi_call has no return value, so only use it when compiled with msvc.
- Modules/_pickle.c
There are Windows data types FLOAT, INT, LONG which the pickle code conflicts with.
- Modules/posixmodule.c
Some "#ifdef _MSC_VER" paragraphs apply for __MINGW32__ as well; for MinGW, wincrypt.h must be explicitely included (the "original" Windows headers include them in windows.h)
- Modules/signalmodule.c
On case-sensitive filesystems, windows.h must be all-lowercase
- Modules/socketmodule.h
MinGW does not define SIO_KEEPALIVE_VALS, so do it here if required
- PC/msvcrtmodule.c
MinGW does not have crtdbg.h
- PC/winreg.c
MinGW does not define REG_LEGAL_CHANGE_FILTER, so do it here if required
- Python/dynload_win.c
strcasecmp is already defined with MinGW, so use a private name
- Python/pythonrun.c
MinGW has locale.h, but not langinfo.h

This patch fixes all the mentioned problems.

----------
components: Build
files: Python-3.1.3.fix_mingw_compile.diff
keywords: patch
messages: 123236
nosy: jonny
priority: normal
severity: normal
status: open
title: Trivial mingw compile fixes
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file19924/Python-3.1.3.fix_mingw_compile.diff

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

From report at bugs.python.org  Fri Dec  3 13:46:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 12:46:28 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291380388.01.0.217134129612.issue10562@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19923/unnamed

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

From report at bugs.python.org  Fri Dec  3 13:46:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 12:46:33 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291380393.6.0.874236386018.issue10197@psf.upfronthosting.co.za>


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

> The function already exists in Python 3.1, but it is not used in Python source code

We don?t know what code out there uses.  This would be an incompatible change.

----------

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

From report at bugs.python.org  Fri Dec  3 13:47:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 12:47:41 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291380461.75.0.548882047232.issue10478@psf.upfronthosting.co.za>


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

Dummy question: why don't you use KeyboardInterrupt instead of a custom SIGINT handler?

try:
    for i in range(1000000):
        print(i)
except KeyboardInterrupt:
    print("got sigint")

Python SIGINT handler raises a KeyboardInterrupt (the handler is written in C, not in Python) which is safe, whereas writing to sys.stdout doesn't look to be a good idea :-)

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Dec  3 13:47:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 12:47:52 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291380472.39.0.0474360954037.issue10557@psf.upfronthosting.co.za>


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

> According to comments in the code and verified by inspection,
> PyOS_string_to_double does not accept any whitespace.

Bah.  You're right, of course.  :-)

Any whitespace (post PyUnicode_EncodeDecimal) is handled in PyFloat_FromString, using Py_ISSPACE.

----------

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

From report at bugs.python.org  Fri Dec  3 14:11:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 13:11:32 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291381892.6.0.960127311745.issue10478@psf.upfronthosting.co.za>


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

This issue remembers me #3618 (opened 2 years ago): I proposed to use RLock instead of Lock, but RLock was implemented in Python and were too slow. Today, we have RLock implemented in C and it may be possible to use them. Would it solve this issue?

--

There are at least two deadlocks, both in _bufferedwriter_flush_unlocked():
 - call to _bufferedwriter_raw_write()
 - call to PyErr_CheckSignals()

> The lock is precisely there so that the buffered object doesn't 
> have to be MT-safe or reentrant. It doesn't seem reasonable
> to attempt to restore the file to a "stable" state in the middle
> of an inner routine.

Oh, so release the lock around the calls to _bufferedwriter_raw_write() (aorund PyObject_CallMethodObjArgs() in _bufferedwriter_raw_write()) and PyErr_CheckSignals() is not a good idea? Or is it just complex because the buffer object have to be in a consistent state?

> (in a more sophisticated version, we could store pending writes 
> so that they get committed at the end of the currently 
> executing write)

If the pending write fails, who gets the error?

----------

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

From report at bugs.python.org  Fri Dec  3 14:11:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 13:11:38 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291381898.36.0.506299178501.issue10478@psf.upfronthosting.co.za>


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

This issue remembers me #3618 (opened 2 years ago): I proposed to use RLock instead of Lock, but RLock was implemented in Python and were too slow. Today, we have RLock implemented in C and it may be possible to use them. Would it solve this issue?

--

There are at least two deadlocks, both in _bufferedwriter_flush_unlocked():
 - call to _bufferedwriter_raw_write()
 - call to PyErr_CheckSignals()

> The lock is precisely there so that the buffered object doesn't 
> have to be MT-safe or reentrant. It doesn't seem reasonable
> to attempt to restore the file to a "stable" state in the middle
> of an inner routine.

Oh, so release the lock around the calls to _bufferedwriter_raw_write() (aorund PyObject_CallMethodObjArgs() in _bufferedwriter_raw_write()) and PyErr_CheckSignals() is not a good idea? Or is it just complex because the buffer object have to be in a consistent state?

> (in a more sophisticated version, we could store pending writes 
> so that they get committed at the end of the currently 
> executing write)

If the pending write fails, who gets the error?

----------

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

From report at bugs.python.org  Fri Dec  3 14:11:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 13:11:52 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291381912.85.0.0414102683877.issue10478@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg123242

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

From report at bugs.python.org  Fri Dec  3 14:24:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Dec 2010 13:24:01 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1291381898.36.0.506299178501.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291382633.3624.4.camel@localhost.localdomain>


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

> This issue remembers me #3618 (opened 2 years ago): I proposed to use
> RLock instead of Lock, but RLock was implemented in Python and were
> too slow. Today, we have RLock implemented in C and it may be possible
> to use them. Would it solve this issue?

I think it's more complicated. If you use an RLock, you can reenter the
routine while the object is in an unknown state, so the behaviour can be
all kinds of wrong.

> > The lock is precisely there so that the buffered object doesn't 
> > have to be MT-safe or reentrant. It doesn't seem reasonable
> > to attempt to restore the file to a "stable" state in the middle
> > of an inner routine.
> 
> Oh, so release the lock around the calls to
> _bufferedwriter_raw_write() (aorund PyObject_CallMethodObjArgs() in
> _bufferedwriter_raw_write()) and PyErr_CheckSignals() is not a good
> idea? Or is it just complex because the buffer object have to be in a
> consistent state?

Both :)

> > (in a more sophisticated version, we could store pending writes 
> > so that they get committed at the end of the currently 
> > executing write)
> 
> If the pending write fails, who gets the error?

Yes, I finally think it's not a good idea. flush() couldn't work
properly anyway, because it *has* to flush the buffer before returning.

----------

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

From report at bugs.python.org  Fri Dec  3 14:30:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 13:30:41 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291383041.62.0.412846523667.issue10478@psf.upfronthosting.co.za>


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

Ok, so +1 to apply immediatly your patch which "fixes" the deadlock. If someone is motived to make Buffered* classes reentrant, (s)he can remove this exception.

io and signal documentation should also be improved to indicate that using buffered I/O in a signal handler may raise a RuntimeError on reentrant call (and give an example to explain the problem?).

About the patch: can't you move "&& (self->owner = PyThread_get_thread_ident(), 1) )" in _enter_buffered_busy()?

----------

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

From report at bugs.python.org  Fri Dec  3 14:41:38 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 03 Dec 2010 13:41:38 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291380388.08.0.733319764327.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTimktZ9+MkUSgv+1M9mJ9d+EHdpK6i=Qw+0ftm3y@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Please make the tokenizer surround spaces around operators. So the output
would be like in the example below:

(1 + 2j)

(1 + 2j)

----------
Added file: http://bugs.python.org/file19925/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
<div>Please make the tokenizer surround spaces around operators. So the output would be like in the example below:</div>
<div>??</div>
<div>&gt;&gt;&gt; 1 + 2j<br>(1 + 2j)</div>
<div>??</div>
<div>Also this:</div>
<div>&gt;&gt;&gt; 1+2j<br>(1 + 2j)</div>

From report at bugs.python.org  Fri Dec  3 14:43:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Dec 2010 13:43:58 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291383838.08.0.85950898647.issue10562@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/issue10562>
_______________________________________

From report at bugs.python.org  Fri Dec  3 14:53:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 13:53:45 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291384425.87.0.327206190455.issue10197@psf.upfronthosting.co.za>


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

Ah, I did not realize that getstatusoutput was implemented using os.popen.  I thought it already used Popen.  Now, in python3, os.popen is in turn implemented using subprocess.Popen, so removing that level of indirection seems sensible.

The question that remains is, does removing the {} change the output obtained from a command sequence in any way?

Note that for backward compatibility you will need to re-munge the status code into C format.  Which makes me wonder if getoutput/getstatusoutput should just be documentationally deprecated instead.  (I never use them myself, FWIW)

----------

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

From report at bugs.python.org  Fri Dec  3 14:59:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Dec 2010 13:59:15 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1291384755.78.0.312861855156.issue1486713@psf.upfronthosting.co.za>


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

A note for the curious: I changed the keyword name from 'tolerant' to 'strict' because the stdlib has other examples of 'strict' as a keyword, but the word 'tolerant' appears nowhere in the documentation and certainly not as a keyword.  So it seemed better to remain consistent with existing practice.  This would be even better if the default value of 'strict' was False, but unfortunately we can't do that.

----------

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

From report at bugs.python.org  Fri Dec  3 15:09:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Dec 2010 14:09:17 +0000
Subject: [issue2380] Raise a Py3K warning for catching nested tuples with
	non-BaseException exceptions
In-Reply-To: <1205812263.49.0.840453912449.issue2380@psf.upfronthosting.co.za>
Message-ID: <1291385357.98.0.997613872951.issue2380@psf.upfronthosting.co.za>


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

Not all incompatibilities have to raise a py3k warnings; AFAIK, only those which are not handled by 2to3 do.

----------
nosy: +benjamin.peterson, pitrou

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

From report at bugs.python.org  Fri Dec  3 15:19:52 2010
From: report at bugs.python.org (Tres Seaver)
Date: Fri, 03 Dec 2010 14:19:52 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1291385992.87.0.707954493142.issue10360@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

This fix needs backporting to the 3.1 and 2.7 branches as well.

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

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

From report at bugs.python.org  Fri Dec  3 15:26:46 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 14:26:46 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291386406.0.0.891898333793.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I brought the patch up to date for the Py3k branch, but realised just before checking it in that it may run afoul of the language moratorium (since it alters the behaviour of builtin range objects).

However, the .count() and .index() methods (along with the Sequence ABC registration) as well as the O(1) containment testing for integers were already put in place. (I also noticed that the new methods from issue #9213 are not mentioned in the range() docs, unlike the O(1) optimisation)

I've gone ahead and checked it in as r86970, as I see this patch as filling out the promise of the Sequence ABC registration by adding support for slicing and negative indices (with the length caching as more of an implementation detail).

However, I'm also leaving the tracker issue open and assigning to Georg in case he wants to revert it before the beta goes out.

Note that I also fixed the patch so that OverflowError occurs only when encountering an affected operation (primarily indexing and retrieval of the length). If you don't do any of those things, you can make your ranges as large as you like. (The indexing could fairly easily be fixed to eliminate the overflow errors - I just didn't do it in this patch, since it is a separate problem).

----------
assignee:  -> georg.brandl
nosy: +georg.brandl
resolution:  -> accepted
stage: patch review -> committed/rejected
title: Precompute range length -> Precompute range length and enhance range subscript support
Added file: http://bugs.python.org/file19926/issue2690_lazy_overflow_check.diff

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

From report at bugs.python.org  Fri Dec  3 15:36:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 14:36:12 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291386972.16.0.287993960267.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added the missing CSS file in r86971. Hopefully that will make the buildbots a little happier.

----------

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

From report at bugs.python.org  Fri Dec  3 16:20:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 15:20:45 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1291389645.21.0.555159452361.issue10360@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Don't worry, it will be ported.

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

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

From report at bugs.python.org  Fri Dec  3 16:21:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 15:21:19 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291389679.88.0.257952981271.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl

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

From report at bugs.python.org  Fri Dec  3 16:21:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 15:21:22 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291389682.88.0.206190526205.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19925/unnamed

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

From report at bugs.python.org  Fri Dec  3 16:22:30 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 03 Dec 2010 15:22:30 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291389750.21.0.411331105301.issue10562@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  3 16:29:14 2010
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 03 Dec 2010 15:29:14 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291390154.41.0.493759271178.issue10576@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

<blockquote>Does anyone think that it is simpler to register two different callbacks than one? </blockquote>

Moderately, yes.

Functions that actually help with cleanup should normally be run only in one phase; it is just stats-gathering and logging functions that might run both times, and I don't mind registering those twice.

For functions that are run only once (which I personally think is the more normal case), the choices are between

    @register_gc
    def my_callback(actually_run_flag, mydict):
        if not actually_run_flag:
            return
        ...

vs

    @register_gc_before
    def my_callback(mydict):
        ...

----------

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

From report at bugs.python.org  Fri Dec  3 17:13:13 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 16:13:13 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291392793.99.0.722542348561.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

r86975 should fix the problem with Windows paths.

I also found an issue where many of the emitted HTML pages contained two HTML header sections. The tests were just written in a way that they only looked at the second of these header sections, while my browser only looked at the first.

The same commit adjusts the tests to look at the first emitted header section and changes the flow in the URL handler to only ever invoke html.page() once per request.

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

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

From report at bugs.python.org  Fri Dec  3 17:14:33 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 16:14:33 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1291392873.04.0.18124434944.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, that would be ?ric's point 4 that I fixed. OK, no need to create a new issue for that one then :)

----------

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

From report at bugs.python.org  Fri Dec  3 17:19:06 2010
From: report at bugs.python.org (Adam Byrtek)
Date: Fri, 03 Dec 2010 16:19:06 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291393146.72.0.354611120105.issue10562@psf.upfronthosting.co.za>


Adam Byrtek <adambyrtek at gmail.com> added the comment:

What happened with "there should be one-- and preferably only one --obvious way to do it"?

----------
nosy: +adambyrtek

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

From report at bugs.python.org  Fri Dec  3 17:26:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Dec 2010 16:26:20 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291393580.74.0.0735339460262.issue2690@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> (I also noticed that the new methods from issue #9213 are not mentioned
> in the range() docs

Wasn't that fixed in Issue9746?

----------

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

From report at bugs.python.org  Fri Dec  3 17:29:47 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 03 Dec 2010 16:29:47 +0000
Subject: [issue10499] Modular interpolation in configparser
In-Reply-To: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>
Message-ID: <1291393787.25.0.98726095758.issue10499@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Committed in rev 86976.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  3 17:35:41 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 16:35:41 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1291393580.74.0.0735339460262.issue2690@psf.upfronthosting.co.za>
Message-ID: <AANLkTinHHy+-93Yxq9EMhAwhPwQppvS6SK=Ep11eDwZS@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Sat, Dec 4, 2010 at 2:26 AM, Daniel Stutzbach <report at bugs.python.org> wrote:
>
> Daniel Stutzbach <stutzbach at google.com> added the comment:
>
>> (I also noticed that the new methods from issue #9213 are not mentioned
>> in the range() docs
>
> Wasn't that fixed in Issue9746?

Ah, I see what you mean. I was more referring to the lack of a
versionchanged note on the range() documentation itself, rather than
the mentioning of range() under the sequence types documentation.

Some of my new additions to the range documentation could probably be
deleted and replaced with a reference to that part of the docs.

Cheers,
Nick.

----------

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

From report at bugs.python.org  Fri Dec  3 17:41:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 16:41:47 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <4CF8BC1C.8070803@egenix.com>
Message-ID: <AANLkTinTT8AEwp4iCg-8m2+G4ZrhgvY34xN4cMe=dcE6@mail.gmail.com>


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

On Fri, Dec 3, 2010 at 4:45 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
>> On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
>> <report at bugs.python.org> wrote:
>> ..
>>> ?* Please change the API _PyUnicode_NormalizeDecimal() to
>>> ? PyUnicode_ConvertToASCIIDecimal() - that's closer to what
>>> ? it does.
>>>
>>
>> Are you sure it is a good idea to give it a public name? ?I have no
>> problem with calling it _PyUnicode_ConvertToASCIIDecimal().
>> ("Transform" may be a better term, though.)
>
> Yes, I think it's useful to have as public API.
>

I am afraid this means it has to go in today.    I'll take the white
space processing out of the public method and try to get the patch
ready for commit.

----------

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

From report at bugs.python.org  Fri Dec  3 17:42:19 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 16:42:19 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291394539.71.0.852044242356.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Daniel Stutzbach pointed out that range() is also mentioned under:
http://docs.python.org/dev/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range

The descriptions of range's limitations there is no longer accurate (slicing is supported following this patch and containment testing is now efficient)

----------
assignee: georg.brandl -> 
status: open -> closed

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

From report at bugs.python.org  Fri Dec  3 17:42:40 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 03 Dec 2010 16:42:40 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291394560.34.0.672557494312.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Given that this is a pure bugfix to revert a problem in 2.7 -- where no *new* development is being done -- a test isn't actually needed for this patch.  There is no point in holding up a distutils1 fix for distutils2's benefit.

Daniel: thanks for the patch, it looks good to me.

----------

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

From report at bugs.python.org  Fri Dec  3 17:43:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 16:43:35 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>


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

b'abc'.partition(':') raises a confusing TypeError('expected an object with the buffer interface'): what is a buffer? what is the buffer interface?

The error comes from PyObject_AsCharBuffer() which is used by:
 - bytes methods: partition, rpartition, find, index, rfind, rindex, count, translate, replace, startswith, endswith
 - complex(): raise a better but incomplete error message on error ("complex() arg is not a string"), incomplete because number is not mentionned
 - float(): raise a better error message on error ("float() argument must be a string or a number")
 - PyArg_Parse*() with the "e" format -> posix.spawnvpe(), imp.load_compiled(), imp.load_source(), imp.load_package()

The error message should be changed to something mentioning classic Python terms. Eg. TypeError("expected bytes, bytearray or buffer compatible object").

----------
components: Interpreter Core
messages: 123263
nosy: haypo
priority: normal
severity: normal
status: open
title: Change PyObject_AsCharBuffer() error message
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec  3 17:48:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 16:48:53 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1291394933.56.0.677016983889.issue6780@psf.upfronthosting.co.za>


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

See also #10616.

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Dec  3 17:49:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 16:49:06 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1291394946.33.0.248162752206.issue10616@psf.upfronthosting.co.za>


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

See also #6780.

----------

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

From report at bugs.python.org  Fri Dec  3 17:52:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Dec 2010 16:52:08 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1291395128.6.0.22487434046.issue10616@psf.upfronthosting.co.za>


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

> complex(): raise a better but incomplete error message on error
> ("complex() arg is not a string"), incomplete because number is not
> mentionned

Fixed by r86977.

----------

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

From report at bugs.python.org  Fri Dec  3 17:53:02 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Dec 2010 16:53:02 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291395182.61.0.882352754281.issue2690@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> The descriptions of range's limitations there is no longer accurate
> (slicing is supported following this patch and containment testing is
> now efficient)

Want to open a new issue for that?  (or is there one already?)

----------

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

From report at bugs.python.org  Fri Dec  3 17:55:55 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Dec 2010 16:55:55 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291395355.8.0.00432065586079.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Oops, didn't mean to reclose this yet)

I want to wait for Georg's verdict on including the functionality in 3.2 before stressing too much about correct documentation of it :)

----------
assignee:  -> georg.brandl
status: closed -> open

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

From report at bugs.python.org  Fri Dec  3 17:57:06 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 03 Dec 2010 16:57:06 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291393146.72.0.354611120105.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTiknAHKoVCy+6dBYaR12u1sPUQrc_sLO4RGpx5zv@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Indeed. There should be spaces around all the operators. Even in my posted
example.

----------
Added file: http://bugs.python.org/file19927/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
Indeed. There should be spaces around all the operators. Even in my posted example.

From report at bugs.python.org  Fri Dec  3 18:08:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 17:08:23 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1291396103.28.0.745658463289.issue10587@psf.upfronthosting.co.za>


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

As discussed in issue10610, it is important to keep the gory details in one place and refer to it throughout the manual.   I think the Unicode terminology is best exposed in the unicodedata module documentation.   For string character-type methods, I suggest presenting an equivalent to unicodedata expression where possible.  For example, x.isalpha() is equivalent to all(unicodedata.category(c) in 'Lu Ll Lt Lm Lo' for c in x) or many be just a "character c is alphabetical if unicodedata.category(c) in 'Lu Ll Lt Lm Lo' is true.

Other examples:

isdigit() -> unicodedata.digit(c, None) is not None
isdecimal() -> unicodedata.decimal(c, None) is not None
isnumeric() -> unicodedata.numeric(c, None) is not None
isprintable()-> unicodedata.category(c) not in 'Cc Cf Cs Co Cn Zl Zp Zs'
islower() -> unicodedata.category(c) == 'Ll'
isupper() -> unicodedata.category(c) == 'Lu'
istitle() -> unicodedata.category(c) == 'Lt'
isalnum() -> isalpha() or isdecimal() or isdigit() or isnumeric()

I am not sure about equivalent to expressions for isidentifier() and isspace().

----------

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

From report at bugs.python.org  Fri Dec  3 18:18:01 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 03 Dec 2010 17:18:01 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291396681.76.0.0628534289304.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Committed Daniel's patch to r86978 in the 2.7 maintenance branch.

(The 2.x trunk still has this bug, but is permanently closed to new checkins.)

----------
stage: needs patch -> committed/rejected
versions:  -3rd party, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec  3 18:18:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 17:18:32 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <AANLkTiknAHKoVCy+6dBYaR12u1sPUQrc_sLO4RGpx5zv@mail.gmail.com>
Message-ID: <AANLkTi=gEwUCxqssKNu71fe8N2AKxsB=XGm_+_ZFt=Pt@mail.gmail.com>


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

On Fri, Dec 3, 2010 at 11:57 AM, Bo?tjan Mejak <report at bugs.python.org> wrote:
..
> Indeed. There should be spaces around all the operators. Even in my posted
> example.

Aim higher: we obviously want Python output look beautiful in print,
so operands should be surrounded by U+2009 (THIN SPACE).

----------

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

From report at bugs.python.org  Fri Dec  3 18:21:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 17:21:56 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291396916.64.0.596877911501.issue2690@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm fine with it: as with the other changes for .count and .index, consistency with the protocols/ABCs the types are members of is not exclusively a new feature.

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

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

From report at bugs.python.org  Fri Dec  3 18:22:37 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 03 Dec 2010 17:22:37 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <AANLkTi=gEwUCxqssKNu71fe8N2AKxsB=XGm_+_ZFt=Pt@mail.gmail.com>
Message-ID: <AANLkTi=N_GEVm0QrQLozH=p1bvxaAYxq8-9c8568Rbmv@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Alexander, is it possible to make an output like (1+2j) be printed as (1 +
2j). Also, why is the result put in parens?

----------
Added file: http://bugs.python.org/file19928/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
Alexander, is it possible to make an output like (1+2j) be printed as (1 + 2j). Also, why is the result put in parens?

From report at bugs.python.org  Fri Dec  3 18:54:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 17:54:28 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1291344829.29.0.413309910585.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTine-fsj68FPmGWjNh+9pvhVsFRBEa_zivqx1f2H@mail.gmail.com>


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

On Thu, Dec 2, 2010 at 9:53 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> ..?The honest reason for the exclusion is that I gave up chasing a bug that only shows
> in full regrtest runs.

I have realized where the problem was. PyUnicode_FromUnicode()
"helpfully" interns single-character  Unicode objects in the Latin-1
range.  So when TransformDecimal replaces whitespace with ' ', it may
garble cached strings.  I think this optimization is a left-over from
the time when unicode did not have interning, but it is never a good
idea to change immutable objects in-place after creation, so I'll fix
this problem in my code.

----------

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

From report at bugs.python.org  Fri Dec  3 19:03:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 18:03:06 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291399386.64.0.0232967199594.issue10562@psf.upfronthosting.co.za>


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

> Alexander, is it possible to make an output like (1+2j)
> be printed as (1 + 2j).

Sure, and 'j' can be highlighted in red, but this is a job for a front-end or a custom display hook, not core python.  You may want to take a look at ipython.

> Also, why is the result put in parens?

There was a historical reason for that, but I don't remember it now.  You may find the answer in the tracker, svn log, or python-dev archives.

It may not have been obvious, but most of the comments here including mine were not serious even when they did not include smileys.  Nothing will happen here.  Time to move on.

----------

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

From report at bugs.python.org  Fri Dec  3 19:03:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 18:03:56 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291399436.12.0.13420741472.issue10562@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19927/unnamed

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

From report at bugs.python.org  Fri Dec  3 19:04:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 18:04:05 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291399445.06.0.0668649216516.issue10562@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19928/unnamed

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

From report at bugs.python.org  Fri Dec  3 19:04:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 18:04:43 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291399483.9.0.917154252456.issue10562@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/issue10562>
_______________________________________

From report at bugs.python.org  Fri Dec  3 19:06:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 18:06:23 +0000
Subject: =?utf-8?q?=5Bissue10617=5D_Collections_ABCs_can=E2=80=99t_be_linked_to?=
In-Reply-To: <1291399583.54.0.437580491631.issue10617@psf.upfronthosting.co.za>
Message-ID: <1291399583.54.0.437580491631.issue10617@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

ABCs in collections.rst are marked up with a class role, not a class directive, which means that constructs using the class role do not generate a link.

----------
assignee: docs at python
components: Documentation
messages: 123277
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Collections ABCs can?t be linked to
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec  3 19:12:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Dec 2010 18:12:07 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1291399927.51.0.167750736398.issue2690@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

The descriptions of range's limitations in the docs still needs an update.

----------
assignee: georg.brandl -> ncoghlan
status: closed -> open

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

From report at bugs.python.org  Fri Dec  3 19:21:15 2010
From: report at bugs.python.org (James Eric Pruitt)
Date: Fri, 03 Dec 2010 18:21:15 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291400475.86.0.710764111424.issue10562@psf.upfronthosting.co.za>


James Eric Pruitt <eric.pruitt at gmail.com> added the comment:

> Also, why is the result put in parens?

Without them, something like 'eval("100 * " + repr(imaginary))' would not work properly.

----------
nosy: +ericpruitt

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

From report at bugs.python.org  Fri Dec  3 19:24:58 2010
From: report at bugs.python.org (Adam Byrtek)
Date: Fri, 03 Dec 2010 18:24:58 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291400698.29.0.316482814426.issue10562@psf.upfronthosting.co.za>


Changes by Adam Byrtek <adambyrtek at gmail.com>:


----------
nosy:  -adambyrtek

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

From report at bugs.python.org  Fri Dec  3 19:28:47 2010
From: report at bugs.python.org (Eric Pruitt)
Date: Fri, 03 Dec 2010 18:28:47 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291400927.02.0.334562543887.issue10562@psf.upfronthosting.co.za>


Changes by Eric Pruitt <eric.pruitt at gmail.com>:


----------
nosy:  -ericpruitt

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

From report at bugs.python.org  Fri Dec  3 19:44:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 03 Dec 2010 18:44:55 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291401895.58.0.354969539563.issue10562@psf.upfronthosting.co.za>


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


----------
assignee: mark.dickinson -> 
nosy:  -mark.dickinson

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

From report at bugs.python.org  Fri Dec  3 19:58:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Dec 2010 18:58:27 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291402707.09.0.238374295287.issue10534@psf.upfronthosting.co.za>


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

Added version-added and committed. r86983

----------

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

From report at bugs.python.org  Fri Dec  3 19:58:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Dec 2010 18:58:54 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291402734.33.0.868513767861.issue10534@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: commit review -> needs patch

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

From report at bugs.python.org  Fri Dec  3 20:04:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Dec 2010 19:04:05 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291403045.88.0.55808127034.issue10562@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  3 20:13:45 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 03 Dec 2010 19:13:45 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1291403045.93.0.816203378005.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=KLqb6bB7jbDe8Ft41aquiDd0ChqkddpVtWjUi@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Parens are okay then. Still, put spaces around operators. If  1 + 2j  let
the output be (1 + 2j)    Please!!!

----------
Added file: http://bugs.python.org/file19929/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
Parens are okay then. Still, put spaces around operators. If ??1 + 2j ??let the output be (1 + 2j) ?? ??Please!!!

From report at bugs.python.org  Fri Dec  3 20:26:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 19:26:11 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1291404371.93.0.648831521636.issue10497@psf.upfronthosting.co.za>


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

Fixed in r86984 (py3k) and r86990 (2.7).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Fri Dec  3 20:27:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 03 Dec 2010 19:27:08 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290901131.19.0.735396835024.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=KyP7XoanUJ=qwM5OV2uGHX5RUcb5eV-rhLnft@mail.gmail.com>


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

On Sat, Nov 27, 2010 at 6:38 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> I suggest Py_UNICODE_ADVANCE() to avoid false suggestion that the iterator protocol is being used.
>

As a data point, ICU defines U16_NEXT() for similar purpose.  I also
like ICU terminology for surrogates ("lead" and "trail") better than
the backward "high" and "low".  The U16_APPEND()  suggests
Py_UNICODE_APPEND instead of PUT_NEXT (this one has a virtue of not
having "next" in the name as well.)  I still like NEXT better than
ADVANCE because it is shorter and has an obvious PREV counterpart that
we may want to add later.

Note that ICU uses U16_ prefix for these macros even when they operate
on 32-bit characters.

More at

http://icu-project.org/apiref/icu4c/utf16_8h.html
http://userguide.icu-project.org/strings

----------

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

From report at bugs.python.org  Fri Dec  3 20:38:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Dec 2010 19:38:20 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291405100.41.0.103615140814.issue10478@psf.upfronthosting.co.za>


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

Fixed in r86981 (3.2), r86987 (3.1) and r86992 (2.7). Thanks!

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

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

From report at bugs.python.org  Fri Dec  3 20:42:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 19:42:45 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1291405365.28.0.74362349864.issue10528@psf.upfronthosting.co.za>


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

Committed in r86993.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Fri Dec  3 20:47:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 19:47:29 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1291405649.34.0.701357783761.issue4391@psf.upfronthosting.co.za>


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

I just checked argparse and there are similar non-optimal calls.  Not all languages can use ?string(s)? to express with 0, 1 or more, that?s why we have ngettext.

Georg: This is a string change similar to #10528.  Does it need a patch and review before the beta1 too?

----------
nosy: +bethard, georg.brandl
priority: low -> 

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

From report at bugs.python.org  Fri Dec  3 20:57:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Dec 2010 19:57:20 +0000
Subject: [issue10272] SSL timeouts should raise socket.timeout,
	not a generic SSLError
In-Reply-To: <1288561433.38.0.641849376879.issue10272@psf.upfronthosting.co.za>
Message-ID: <1291406240.2.0.662592899849.issue10272@psf.upfronthosting.co.za>


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

Requalifying this issue so that the ssl module is fixed to raise socket.timeout on socket timeouts, which is not only more logical but much more useful (since you can then specifically handle this error).

----------
priority: low -> normal
title: SSL handshake timeouts not caught by transient_internet -> SSL timeouts should raise socket.timeout, not a generic SSLError
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Dec  3 21:00:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Dec 2010 20:00:12 +0000
Subject: [issue10272] SSL timeouts should raise socket.timeout,
	not a generic SSLError
In-Reply-To: <1288561433.38.0.641849376879.issue10272@psf.upfronthosting.co.za>
Message-ID: <1291406412.27.0.439462720698.issue10272@psf.upfronthosting.co.za>


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

Committed in r86997. I won't backport it to bugfix branches since it is a small compatibility breach.

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

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

From report at bugs.python.org  Fri Dec  3 21:01:02 2010
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 03 Dec 2010 20:01:02 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291406462.77.0.387910380323.issue10576@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Fri Dec  3 21:01:56 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 03 Dec 2010 20:01:56 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1291406516.43.0.73689301496.issue9333@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks and good work, Brian.

I think ,though, I'm leaning toward agreeing with Amaury on the presence of the symlink attribute in os.

I can easily see the justification for hiding it in legacy environments (Windows XP & Server 2003), where the relevance diminishes over time, but since we're talking about Python 3, with limited adoption, I'm inclined to suggest it's better to err on the side of breaking existing code and getting the code right, rather than backward compatibility.

To me, the test `hasattr(os, 'symlink')` does not effectively communicate the nuances of the underlying functionality. It doesn't provide a run-time environment any data on why it may or may not be present.

While it does provide excellent backward compatibility (based on a survey of use-cases), I worry it's not the best solution, and might be undesirable in the long run.

Would it be possible to provide a `can_symlink` or `user_can_symlink` function which would be recommended to replace the `hasattr` test? Perhaps we consider keeping the current implementation, deprecate the use of the hasattr test, and prepare for a change in 3.3 or 3.4 where the symlink method is always present on Windows systems >= 6.0.

I defer to Brian's opinion on this, but did want to share my mild discomfort with the current implementation.

----------

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

From report at bugs.python.org  Fri Dec  3 21:12:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 03 Dec 2010 20:12:52 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTi=KyP7XoanUJ=qwM5OV2uGHX5RUcb5eV-rhLnft@mail.gmail.com>
Message-ID: <4CF94F33.8050805@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Sat, Nov 27, 2010 at 6:38 PM, Raymond Hettinger
> <report at bugs.python.org> wrote:
> ..
>> I suggest Py_UNICODE_ADVANCE() to avoid false suggestion that the iterator protocol is being used.
>>
> 
> As a data point, ICU defines U16_NEXT() for similar purpose.  I also
> like ICU terminology for surrogates ("lead" and "trail") better than
> the backward "high" and "low". 

"High" and "low" are Unicode standard terms, so we should use
those.

Regarding Py_UCS4_READ_CODE_POINT: you're right that surrogates
are code points, so how about Py_UCS4_READ_NEXT() ?!

Regarding Py_UCS4_READ_NEXT() vs. Py_UNICODE_READ_NEXT(): the return
value of the macro is a Py_UCS4 value, not a Py_UNICODE value. The
first argument of the macro can be any array, not just Py_UNICODE*,
but also Py_UCS4* or even int*.

Py_UCS2_READ_NEXT() would be plain wrong :-) Also note that Python
does have a Py_UCS4 type; it doesn't have a Py_UCS2 type.

That's why we should use *Py_UCS4*_READ_NEXT().

----------

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

From report at bugs.python.org  Fri Dec  3 21:21:47 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 03 Dec 2010 20:21:47 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

http://mercurial.selenic.com/bts/issue2534 is a regression in 2.7.1 relative to 2.7, around the way commands are called (it seems to concern subprocess.call()). The error seems to be raised from mercurial's util.system() call, which uses subprocess.call() or subprocess.Popen() depending on the circumstances.

----------
components: Library (Lib)
messages: 123291
nosy: asksol, djc, jnoller
priority: normal
severity: normal
status: open
title: regression in subprocess.call() command quoting
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec  3 21:30:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 20:30:48 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1291408248.46.0.93090954781.issue10618@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The culprit seems to be r83957, which was done to fix #2304.  Assigning to Tim, who committed that revision.

----------
assignee:  -> tim.golden
nosy: +georg.brandl, tim.golden

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

From report at bugs.python.org  Fri Dec  3 21:39:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Dec 2010 20:39:11 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1291408751.89.0.752893405325.issue10618@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In util.system(), Mercurial adds its own pair of quotes:

    if os.name == 'nt':
        cmd = '"%s"' % cmd

That will result in one level of quoting too much.

Now it seems unfortunate that this change was done in a minor version.
It is definitely a bug fix, but one that many users have already worked around, probably in the same way as Mercurial.

Possible ways to resolve:

* make addition of quotes Python-version-specific in Mercurial
* revert to old behavior in Python 2.7.2 (ugly)
* add a check for quotes around the string in Python 2.7.2, and refrain from adding another set of quotes

(Adding 2.7 release manager to nosy.)

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

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

From report at bugs.python.org  Fri Dec  3 21:55:10 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 03 Dec 2010 20:55:10 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1291409710.05.0.582735478424.issue10618@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Ask, Jesse, sorry, I got confused about multiprocessing and subprocess. Taking you out of the nosy now.

----------
nosy:  -asksol, jnoller

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

From report at bugs.python.org  Fri Dec  3 22:03:53 2010
From: report at bugs.python.org (Jeff Laughlin)
Date: Fri, 03 Dec 2010 21:03:53 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1291410233.07.0.829580938043.issue2624@psf.upfronthosting.co.za>


Changes by Jeff Laughlin <jeff.laughlin at gmail.com>:


----------
nosy: +Jeff.Laughlin

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

From report at bugs.python.org  Fri Dec  3 22:04:01 2010
From: report at bugs.python.org (Jeff Laughlin)
Date: Fri, 03 Dec 2010 21:04:01 +0000
Subject: [issue1016626] distutils support for swig is under par
Message-ID: <1291410241.51.0.823944662819.issue1016626@psf.upfronthosting.co.za>


Changes by Jeff Laughlin <jeff.laughlin at gmail.com>:


----------
nosy: +Jeff.Laughlin

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

From report at bugs.python.org  Fri Dec  3 22:36:15 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 03 Dec 2010 21:36:15 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1291412175.1.0.185210804985.issue9101@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  3 22:49:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 03 Dec 2010 21:49:51 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291412991.65.0.680803672613.issue10367@psf.upfronthosting.co.za>


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

> a test isn't actually needed for this patch.

This is incorrect.

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

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

From report at bugs.python.org  Fri Dec  3 22:56:21 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 03 Dec 2010 21:56:21 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1291413381.67.0.704600769292.issue9101@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Fixed in rev 86976.

----------

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

From report at bugs.python.org  Fri Dec  3 22:58:57 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Dec 2010 21:58:57 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291413537.42.0.468208349978.issue10367@psf.upfronthosting.co.za>


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

Philip, Eric is currently assigned to this issue, and was working on a test, obviously.

It means that commiting a fix without a test without asking him first is is quite rude.

He and I are maintaining Distutils. Your help is welcome but please do not commit in this area without discussion in particular when the bug is assigned to someone. 

Now if you could provide a test for your change, we would highly appreciate it. Thanks

----------

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

From report at bugs.python.org  Fri Dec  3 23:28:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Dec 2010 22:28:49 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291415329.89.0.0940810598524.issue10197@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See also Issue9922

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Dec  3 23:32:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Dec 2010 22:32:09 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291415529.19.0.714359556122.issue10534@psf.upfronthosting.co.za>


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

Deprecated isbjunk and isbpopular methods, ran doc and unit tests, and committed as r87000. Still need to add 'gone in 3.3 test' when revise unittests.

----------

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

From report at bugs.python.org  Fri Dec  3 23:33:50 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 03 Dec 2010 22:33:50 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1291415630.74.0.445844793419.issue7904@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Though msg104261 suggests this change be documented in NEWS.txt, it doesn't appear to have made it.

Sure enough, we just found application code that this broke.

----------
nosy: +fdrake

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

From report at bugs.python.org  Fri Dec  3 23:37:04 2010
From: report at bugs.python.org (Daniel Tavares)
Date: Fri, 03 Dec 2010 22:37:04 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1291413537.42.0.468208349978.issue10367@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=W_6G7X+ksMaJ7pvZ0y1FZc+SxMWjfWP2Jfv3O@mail.gmail.com>


Daniel Tavares <danielmtavares at gmail.com> added the comment:

I'll gladly work on the test, unless someone is working on it already. I
apologize for not sending it originally along with the patch. Since Eric
only requested the diff, I thought a test wasn't needed.

Cheers,
Daniel

On Fri, Dec 3, 2010 at 1:58 PM, Tarek Ziad?? <report at bugs.python.org> wrote:

>
> Tarek Ziad?? <ziade.tarek at gmail.com> added the comment:
>
> Philip, Eric is currently assigned to this issue, and was working on a
> test, obviously.
>
> It means that commiting a fix without a test without asking him first is is
> quite rude.
>
> He and I are maintaining Distutils. Your help is welcome but please do not
> commit in this area without discussion in particular when the bug is
> assigned to someone.
>
> Now if you could provide a test for your change, we would highly appreciate
> it. Thanks
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10367>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19930/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________
-------------- next part --------------
I&#39;ll gladly work on the test, unless someone is working on it already. I apologize for not sending it originally along with the patch. Since Eric only requested the diff, I thought a test wasn&#39;t needed.<br><br>Cheers,<br clear="all">
Daniel<br>
<br><br><div class="gmail_quote">On Fri, Dec 3, 2010 at 1:58 PM, Tarek Ziad?? <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;">
<br>
Tarek Ziad?? &lt;<a href="mailto:ziade.tarek at gmail.com">ziade.tarek at gmail.com</a>&gt; added the comment:<br>
<br>
Philip, Eric is currently assigned to this issue, and was working on a test, obviously.<br>
<br>
It means that commiting a fix without a test without asking him first is is quite rude.<br>
<br>
He and I are maintaining Distutils. Your help is welcome but please do not commit in this area without discussion in particular when the bug is assigned to someone.<br>
<br>
Now if you could provide a test for your change, we would highly appreciate it. Thanks<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue10367" target="_blank">http://bugs.python.org/issue10367</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Dec  3 23:38:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 22:38:33 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291415913.48.0.333805529919.issue10367@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19930/unnamed

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

From report at bugs.python.org  Fri Dec  3 23:40:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 03 Dec 2010 22:40:52 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291416052.84.0.95414303309.issue10615@psf.upfronthosting.co.za>


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

When the patch is applied, what's the resulting status of mingw compilation?

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

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

From report at bugs.python.org  Fri Dec  3 23:46:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 22:46:54 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291416414.8.0.0993079549285.issue10367@psf.upfronthosting.co.za>


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

Thanks Daniel.  The links in my last message should get you started, and any questions are welcome.

You may be interested in this sprint: http://wiki.montrealpython.org/index.php/Packaging_no.10  I will be on IRC for some hours that night.

----------
stage: committed/rejected -> needs patch
versions: +3rd party

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

From report at bugs.python.org  Fri Dec  3 23:50:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Dec 2010 22:50:57 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291416657.44.0.746200037314.issue10534@psf.upfronthosting.co.za>


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

News entry for both commits: r87001

----------

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

From report at bugs.python.org  Fri Dec  3 23:54:47 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 03 Dec 2010 22:54:47 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291416887.06.0.328981675395.issue10615@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

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

From report at bugs.python.org  Fri Dec  3 23:57:09 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 03 Dec 2010 22:57:09 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291417029.77.0.299356461043.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Whoops, my bad...  I misread Eric's earlier message as throwing it back onto *Daniel* to produce a test, not that *he* (Eric) was working on the test.

IOW, I thought that progress had been stalled a second time on this, and went ahead to pick up the slack.  Sorry about that.

----------

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

From report at bugs.python.org  Sat Dec  4 00:05:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Dec 2010 23:05:05 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291417505.45.0.776620817586.issue10367@psf.upfronthosting.co.za>


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

You understood right: I asked for a test using the mock PyPI server in distutils2.  ?I can?t do it? is a valid reply, in which case it would have been picked up by someone else or me.

You could say that progress has stalled, but there was no urgency, given that the next 2.7 release is not tomorrow.  We have more than a hundred bugs on our hands, so waiting a few days for a reply is not a problem :)

Misunderstandings aside, thanks for your help.

----------
priority: high -> 

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

From report at bugs.python.org  Sat Dec  4 00:41:05 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 03 Dec 2010 23:41:05 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291419665.8.0.0879639894528.issue10367@psf.upfronthosting.co.za>


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

Ugh sorry I thought Eric was working on a test. I  misunderstood.

----------

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

From report at bugs.python.org  Sat Dec  4 01:14:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 04 Dec 2010 00:14:24 +0000
Subject: [issue10619] Failed module loading in test discovery loses traceback
In-Reply-To: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za>
Message-ID: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za>


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

If a test module fails to load during unittest test discovery (SyntaxError or other exception) then the error is reported during the test run.

Due to the way the exception is re-raised the traceback is lost.

Originally reported as unittest2 issue 29: https://code.google.com/p/unittest-ext/issues/detail?id=29

----------
assignee: michael.foord
components: Library (Lib)
messages: 123308
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Failed module loading in test discovery loses traceback
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Dec  4 01:20:07 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 04 Dec 2010 00:20:07 +0000
Subject: [issue10620] `python -m uniittest` should work with file paths as
	well as test module names
In-Reply-To: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za>
Message-ID: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za>


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

Feature request against unittest2. Issue 18: https://code.google.com/p/unittest-ext/issues/detail?id=18

As providing a file path instead of module name to the unittest command line runner currently fails there is no backwards compatibility issue with making this work.

The only potential issue is if a test suite or module is genuinely 'foo.py' then we could end up attempting to load the file instead of the specified suite / module. To get round this we should only attempt to load tests from a file by checking the file exists first.

The specified still needs to be *imported* to load tests from it, so the file path will be converted to a module name by replacing path separators with '.'.

The way to execute test files that aren't importable as modules is to execute them directly not using `python -m unittest`.

----------
assignee: michael.foord
components: Library (Lib)
messages: 123309
nosy: michael.foord
priority: normal
severity: normal
status: open
title: `python -m uniittest` should work with file paths as well as test module names
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  4 01:32:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 00:32:11 +0000
Subject: [issue10619] Failed module loading in test discovery loses traceback
In-Reply-To: <1291421664.92.0.199127782586.issue10619@psf.upfronthosting.co.za>
Message-ID: <1291422731.73.0.896539223933.issue10619@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 01:32:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 00:32:18 +0000
Subject: [issue10620] `python -m uniittest` should work with file paths as
	well as test module names
In-Reply-To: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za>
Message-ID: <1291422738.94.0.153914185847.issue10620@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 01:32:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Dec 2010 00:32:49 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291422769.75.0.402527114716.issue10562@psf.upfronthosting.co.za>


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


----------
nosy:  -rhettinger

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

From report at bugs.python.org  Sat Dec  4 02:12:28 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 04 Dec 2010 01:12:28 +0000
Subject: [issue10620] `python -m uniittest` should work with file paths as
	well as test module names
In-Reply-To: <1291422007.54.0.147727211127.issue10620@psf.upfronthosting.co.za>
Message-ID: <1291425148.41.0.652514261293.issue10620@psf.upfronthosting.co.za>


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

Committed revision 87003.

----------
resolution:  -> fixed
stage:  -> committed/rejected

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

From report at bugs.python.org  Sat Dec  4 02:39:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 01:39:58 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1291426798.1.0.625048789225.issue9101@psf.upfronthosting.co.za>


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

Can you make the same addition in the docs of 3.1 and 2.7?

----------

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

From report at bugs.python.org  Sat Dec  4 02:45:45 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 04 Dec 2010 01:45:45 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1291427145.5.0.342288561466.issue6210@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

It seems to me that an explicit raise inside an except block should *not* chain exceptions by default. The rationale for chaining exceptions is to detect bugs in the exception handler:

try:
    something
except SomeError:
    y = 1/x  # oops, what happens when x == 0?

but an explicit raise isn't a bug. If you want it to chain for some reason, it's easy to do: 

try:
    something
except SomeError as exp:
    raise MyException from exp

or otherwise set __content__, but there's no simple way to avoid chaining except via boilerplate code.

I frequently use the EAFP idiom to detect error conditions, and chained exceptions exposes details to the caller that are irrelevant implementation details. Here's a common example:

def process(iterable):
    try:
        x = next(iterable)
    except StopIteration:
        raise ValueError("can't process empty iterable")
    continue_processing()

The fact that ValueError was raised in response to a StopIteration is an irrelevant implementation detail that shouldn't be, and wasn't in 2.x, exposed.

Another practical example is avoiding isinstance checks:

def func(x):
    try:
        x + 0
    except (ValueError, TypeError):
        raise MyException('x is not a number')
    do_something_with(x)


I note that PEP 3134 explicitly listed the issue of *not* chaining exceptions as an open issue. Now that chained exceptions are being seen in the wild, it seems that the inability to easily suppress chaining *is* a real issue for some users:

http://mail.python.org/pipermail/python-list/2010-October/1258583.html
http://mail.python.org/pipermail/python-list/2010-December/1261738.html

----------
nosy: +stevenjd

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

From report at bugs.python.org  Sat Dec  4 03:21:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Dec 2010 02:21:37 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291408751.89.0.752893405325.issue10618@psf.upfronthosting.co.za>
Message-ID: <AANLkTimGVB4=Py9u-ch-Zy6AHjUcyiubXxr4W-U3dfeq@mail.gmail.com>


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

2010/12/3 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
> In util.system(), Mercurial adds its own pair of quotes:
>
> ? ?if os.name == 'nt':
> ? ? ? ?cmd = '"%s"' % cmd
>
> That will result in one level of quoting too much.
>
> Now it seems unfortunate that this change was done in a minor version.
> It is definitely a bug fix, but one that many users have already worked around, probably in the same way as Mercurial.
>
> Possible ways to resolve:
>
> * make addition of quotes Python-version-specific in Mercurial
> * revert to old behavior in Python 2.7.2 (ugly)
> * add a check for quotes around the string in Python 2.7.2, and refrain from adding another set of quotes

I think we should just leave it alone. If it change the behavior again
in 2.7.2, it'll be even more consistent than before.

----------

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

From report at bugs.python.org  Sat Dec  4 03:22:50 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 04 Dec 2010 02:22:50 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291429370.84.0.429653907743.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

The urgency was only that I didn't want the other contributors to this issue to feel as though the bar on their contributions were being raised higher every time they jumped the previous bar.

IOW, I did it to make them feel like somebody was doing *something*.  In hindsight, that was not necessarily the best tactic.  ;-)

(Given the nature of the bugfix and the bugfix-only status of the 2.7 line, I don't think the lack of an automated test is a big deal; the odds that anything other than trivial bugfixes will be applied to this module in the future seem negligible to me.  At least, I would *hope* that it is not planned to destabilize this module in 2.7.x any further than it already was by the changes that broke it in the first place.)

----------

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

From report at bugs.python.org  Sat Dec  4 04:05:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 04 Dec 2010 03:05:00 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291431900.4.0.589872972308.issue10557@psf.upfronthosting.co.za>


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

Hopefully this is the last iteration before commit.  As discussed, I took whitespace processing out of PyUnicode_TransformDecimalToASCII() and made it public.  Whitespace conversion in int()/float()/complex() is repetitious and can be optimized by, for example only converting leading and trailing whitespace.  I erred on the side of correctness here and real optimization will come from making conversion algorithms operate directly on Py_UNICODE characters.  This looks like a relatively easy thing to do, but is definitely outside of the scope of this issue.

----------
Added file: http://bugs.python.org/file19931/issue10557d.diff

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

From report at bugs.python.org  Sat Dec  4 04:43:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 04 Dec 2010 03:43:19 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291434199.87.0.58365444554.issue10557@psf.upfronthosting.co.za>


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

Committed in revision 87007.  As a bug fix, this needs to be backported to 3.1, but PyUnicode_TransformDecimalToASCII() should probably be renamed to _PyUnicode_TransformDecimalToASCII() to avoid introduction of a new feature.

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

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

From report at bugs.python.org  Sat Dec  4 08:36:05 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 07:36:05 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1291448165.05.0.449550837293.issue10534@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry,

Attaching a patch with the following:

1. Added unittest assertions for bjunk and bpopular data attributes. 
2. Minor markup & formatting fixes in one paragraph of the doc difflib.rst

----------
Added file: http://bugs.python.org/file19932/issue10534.2.patch

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

From report at bugs.python.org  Sat Dec  4 09:32:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 08:32:34 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1291451554.7.0.325572489018.issue6210@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

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

From report at bugs.python.org  Sat Dec  4 09:32:35 2010
From: report at bugs.python.org (Johann Hanne)
Date: Sat, 04 Dec 2010 08:32:35 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291451555.25.0.93226110368.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

>When the patch is applied, what's the resulting status of mingw compilation?

It compiles all C files which I require. Not sure if this is really *all* C files, but at least very close to all. I will post a list of object files I get on Monday.

----------

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

From report at bugs.python.org  Sat Dec  4 09:34:02 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 08:34:02 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1291451642.88.0.784916842776.issue766910@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alexander, 

I reviewed the patch and ported the changes to the newest sources (since the fix to issue 9299, os.makedirs can be naturally used with its new flag to fix the bug Zooko refers to).

However, while experimenting, I think I ran into much larger problems. Either that or I've forgotten how to use the module :-) Attaching two files (one imports the other) on which I try to run the following:

python -m trace -c trace_target.py

>> OK: I get trace_target.cover & traced_module.cover created

However, now running:

python -m trace -r --file=trace_target.cover

>> ...
    pickle.load(open(self.infile, 'rb'))
_pickle.UnpicklingError: invalid load key, ' '.

Also, trying to provide --file to -c:

python -m trace -c trace_target.py --file=xyz.cover

>> xyz.cover is ignored and the same two .cover files are created.

Can you take a look at this?

----------
Added file: http://bugs.python.org/file19933/trace_target.py

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

From report at bugs.python.org  Sat Dec  4 09:34:21 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 08:34:21 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1291451661.49.0.400124373356.issue766910@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Added file: http://bugs.python.org/file19934/traced_module.py

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

From report at bugs.python.org  Sat Dec  4 09:44:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Dec 2010 08:44:54 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291451555.25.0.93226110368.issue10615@psf.upfronthosting.co.za>
Message-ID: <4CF9FF84.2010606@v.loewis.de>


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

Am 04.12.2010 09:32, schrieb Johann Hanne:
> 
> Johann Hanne <python at jf.hanne.name> added the comment:
> 
>> When the patch is applied, what's the resulting status of mingw compilation?
> 
> It compiles all C files which I require. Not sure if this is really *all* C files, but at least very close to all. I will post a list of object files I get on Monday.

Will it then also link something?

----------

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

From report at bugs.python.org  Sat Dec  4 09:54:04 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 08:54:04 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291452844.65.0.965526321369.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Was list.copy() also approved? After all, there are many ways to achieve the same even now:

1. L[:]
2. list(L)
3. import copy and then copy.copy

Especially re the last one: list.copy() can be deep or shallow, which one should it be?

----------

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

From report at bugs.python.org  Sat Dec  4 09:59:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 08:59:25 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291453165.61.0.997520663949.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Also, where is the *official* place to document list objects and their methods?

----------

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

From report at bugs.python.org  Sat Dec  4 10:15:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 09:15:39 +0000
Subject: [issue6045] Add more dict methods to dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1291454139.71.0.106325556432.issue6045@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

r87013 adds get() and setdefault() to dbm.gnu -- now gdbm and ndbm have the same set of dict methods available.

For me, that is enough to demote this to feature request.

There's another issue anyway for iteration protocol support.

----------
priority: critical -> normal
title: Fix dbm interfaces -> Add more dict methods to dbm interfaces
type: behavior -> feature request
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Sat Dec  4 10:21:49 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 04 Dec 2010 09:21:49 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Python interpreter should put spaces around operators in return values of complex numbers. If you give it
>>> 1 + 2j
it should return
(1 + 2j)
and not the current
(1+2j)

My argument is that complex numbers are written like this, with spaces surrounding operators. Wikipedia has multiple instances of the complex number writren, and it's x + yi (in our world it's x + yj but you get the point and you can see that there are spaces around the operator). Please fix the tokenizer to do the right thing.

----------
components: IO
messages: 123324
nosy: Retro
priority: normal
severity: normal
status: open
title: >>> 1 + 2j --> (1 + 2j) and not (1+2j)
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Dec  4 10:22:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 09:22:10 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291454530.19.0.402315064493.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, list.copy was also approved IIRC.  And it should be a shallow copy, like all other copy methods on builtins.

----------

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

From report at bugs.python.org  Sat Dec  4 10:32:37 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 04 Dec 2010 09:32:37 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291455157.1.0.860132901109.issue10516@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

This is really welcome. It makes Python even more readable.

If 'a' is a list object, a[:] is not so obvious at first to a newcomer, but
a.copy() is.

Also, a.clear() is so perfect and understandable. I wish you could decorate Python versions prior to 3.3 with this two new list methods.

----------
nosy: +Retro

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

From report at bugs.python.org  Sat Dec  4 11:02:43 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 04 Dec 2010 10:02:43 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1291415630.74.0.445844793419.issue7904@psf.upfronthosting.co.za>
Message-ID: <20101204100057.GA3487@rubuntu>


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

On Fri, Dec 03, 2010 at 10:33:50PM +0000, Fred L. Drake, Jr. wrote:
> Though msg104261 suggests this change be documented in NEWS.txt, it
> doesn't appear to have made it.

Better late than never. I just added the NEWS in r87014 (py3k)
,r87015(release31-maint) ,r87016(release27-maint).

----------

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

From report at bugs.python.org  Sat Dec  4 11:26:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 10:26:55 +0000
Subject: [issue10553] Add optimize argument to builtin compile() and
	byte-compilation modules
In-Reply-To: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>
Message-ID: <1291458415.58.0.114241273764.issue10553@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added PyZipFile API, and fixed the "optimze". Committed in r87019.

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

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

From report at bugs.python.org  Sat Dec  4 11:33:04 2010
From: report at bugs.python.org (Tim Golden)
Date: Sat, 04 Dec 2010 10:33:04 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291408751.89.0.752893405325.issue10618@psf.upfronthosting.co.za>
Message-ID: <4CFA18DB.1090700@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I'm not quite sure how anyone's supposed to determine
which bugs are likely to have been worked around and
which haven't :) I'm also unsure why a clear bugfix
shouldn't make it into a minor version release. Surely
this isn't the only one to do so...

I'm happy to repatch/test to strip quotes before adding,
but I see that Benjamin prefers to leave it alone.

----------

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

From report at bugs.python.org  Sat Dec  4 11:38:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 10:38:30 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291459110.56.0.952179308995.issue10621@psf.upfronthosting.co.za>


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

I suggest closing this as 'won't fix' (or even the apostrophetically-challenged 'wont fix').  I'll leave it open for a while to allow others to comment.

I have some sympathy for the idea: I also think that the str/repr of a complex number would look better with spaces (and without parentheses (and with 'i' in place of 'j'))).  I've always appreciated the fact that lists are printed in the form '[1, 2, 3]' rather than the less readable '[1,2,3]'.

But there's a big difference between 'it might have been better if ...' and 'it's worth changing this'.  Tinkering with minor details like this from release to release just isn't worth the potential difficulties (however minor) caused to users as they have to adapt their code.  The current behaviour is perfectly serviceable.

P.S.  What's the tokenizer got to do with this?

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

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

From report at bugs.python.org  Sat Dec  4 11:39:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 10:39:45 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1291459185.51.0.696724463005.issue1513299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed what was left applicable of the patch in r87020.

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

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

From report at bugs.python.org  Sat Dec  4 11:45:08 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 04 Dec 2010 10:45:08 +0000
Subject: [issue10614] ZipFile and CP932 encoding
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1291459508.48.0.479445220948.issue10614@psf.upfronthosting.co.za>


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

I'm not sure why, but I got BadZipFile error now. Anyway,
here is cp932 zip file to be created with python2.7.

----------
Added file: http://bugs.python.org/file19935/non-ascii-cp932.zip

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

From report at bugs.python.org  Sat Dec  4 11:47:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 10:47:59 +0000
Subject: [issue1772833] -q (quiet) option for python interpreter
Message-ID: <1291459679.86.0.156016947288.issue1772833@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Based on the +1's in #1728488, committed in r87021, with addition to the command-line docs.

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

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

From report at bugs.python.org  Sat Dec  4 12:02:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 11:02:33 +0000
Subject: [issue1569291] Speed-up in array_repeat()
Message-ID: <1291460553.44.0.176413859885.issue1569291@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I changed the patch to look more like unicode_repeat (which addresses Alex' point #2) and committed in r87022.

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

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

From report at bugs.python.org  Sat Dec  4 12:03:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 11:03:19 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291460599.21.0.736219181329.issue10557@psf.upfronthosting.co.za>


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

Looks okay, I guess.

I don't much like the extra boilerplate that's introduced (and repeated) in longobject.c, floatobject.c and complexobject.c, though.

----------

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

From report at bugs.python.org  Sat Dec  4 12:13:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 11:13:06 +0000
Subject: [issue7905] Shelf 'keyencoding' keyword argument is undocumented and
	does not work.
In-Reply-To: <1265858045.44.0.437187909795.issue7905@psf.upfronthosting.co.za>
Message-ID: <1291461186.52.0.161111350793.issue7905@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patched up and committed in r87024.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Dec  4 12:22:25 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Dec 2010 11:22:25 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1291461745.77.0.796728140724.issue6559@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I've committed this feature just in time for 3.2beta1 (so it can't be said i'm adding a feature after the beta ;).  r87026

It still needs tests and documentation.  It doesn't break any existing tests.

I'll take care of that after some sleep.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

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

From report at bugs.python.org  Sat Dec  4 12:32:34 2010
From: report at bugs.python.org (Davide Rizzo)
Date: Sat, 04 Dec 2010 11:32:34 +0000
Subject: [issue10622] WebKit browsers show superfluous scrollbars in html docs
In-Reply-To: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za>
Message-ID: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

Some WebKit browsers show a superflous scrollbar on the right side of the <pre> boxes in the Sphinx generated html docs.

For example:
http://666kb.com/i/boxys2zktxky17vsh.png
taken on Chrome 7 on Windows.

I believe that the cause of the behaviour is a bug in the WebKit engine. If that's the case, adding "overflow-y: hidden" to the <pre> css style would fix the issue.
"overflow-y" is not standard css, but it is understood by the affected browsers, looks ok on other modern browsers and is just ignored on older releases.

The provided patch has been tested on all major Windows browsers.

----------
assignee: docs at python
components: Documentation
files: webkit.patch
keywords: patch
messages: 123338
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: WebKit browsers show superfluous scrollbars in html docs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19936/webkit.patch

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

From report at bugs.python.org  Sat Dec  4 12:39:28 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Dec 2010 11:39:28 +0000
Subject: [issue10622] WebKit browsers show superfluous scrollbars in html docs
In-Reply-To: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za>
Message-ID: <1291462768.18.0.0462765805448.issue10622@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r87027 has it for py3k / 3.2.  needs backporting to the other branches.

----------
nosy: +gregory.p.smith
versions:  -Python 3.2

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

From report at bugs.python.org  Sat Dec  4 13:27:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 12:27:44 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291465664.15.0.73110262793.issue10596@psf.upfronthosting.co.za>


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

Fixed the sign of the zero (in py3k) in r87032.  I'll backport to 2.7 and 3.1, then close this.

Sergio, is that acceptable?  You still haven't said what results you were expecting for these operations.

----------
resolution:  -> fixed
stage:  -> committed/rejected
versions: +Python 2.7, Python 3.1 -Python 2.6

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

From report at bugs.python.org  Sat Dec  4 13:30:26 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 12:30:26 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291465826.59.0.00736159073404.issue10621@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree. It would be nice, but the impact on existing code is too large. I can easily imagine someone parsing the output of "print(somecomplexnumber)" and not considering spaces.

For the record, it would require changing complex.__repr__  (which is also complex.__str__) and complex.__format__.

Now that I look at the code, it seems that complex_format is only called from one place (complex_repr), with fixed parameters. It could be moved into complex_repr for what I think is a small improvement in readability.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sat Dec  4 13:51:12 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 04 Dec 2010 12:51:12 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291465826.59.0.00736159073404.issue10621@psf.upfronthosting.co.za>
Message-ID: <AANLkTin_0jQ2e7GVas_+mY0=SJia0c_yz8RsGN7M8GN9@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Please do the move to complex_repr if everything then works the same (i.e.
nothing breaks the build) if the readability is in fact improved. Also,
change the docs and fix the tests. You know the drill.

P.S.: (1+2j) is worth changing to become (1 + 2j) in the future (in Python
3.3 if not sooner?). Is it very hard to do this? It's worth changing this.
Reasons like 'Readability counts.' come into mind...

----------
Added file: http://bugs.python.org/file19937/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________
-------------- next part --------------
<div>Please do the move to complex_repr if everything then works the same (i.e. nothing breaks the build) if the readability is in fact improved. Also, change the docs and fix the tests. You know the drill.</div><div><br></div>
<div>P.S.: (1+2j) is worth changing to become (1 + 2j) in the future (in Python 3.3 if not sooner?). Is it very hard to do this? It&#39;s worth changing this. Reasons like &#39;Readability counts.&#39; come into mind...</div>

From report at bugs.python.org  Sat Dec  4 13:55:21 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 12:55:21 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291467321.83.0.901557275344.issue10621@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

There are no tests or docs to fix: it's an internal (static) helper function.

It's not a particularly straightforward change, because you're inserting a space into the middle of the floating point imaginary string. There would be extra bookkeeping and memory management going on.

But even if it were easy, I disagree that it's worth breaking existing usages of complex.__str__, .__repr__, and .__format__.

----------

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

From report at bugs.python.org  Sat Dec  4 14:06:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 13:06:43 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291468003.92.0.94874466417.issue10596@psf.upfronthosting.co.za>


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

Backported to 3.1 (after one botched backport attempt) and 2.7 in r87037 and r87033.

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

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

From report at bugs.python.org  Sat Dec  4 14:08:14 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 04 Dec 2010 13:08:14 +0000
Subject: =?utf-8?q?=5Bissue10623=5D_What=E2=80=99s_New_In_Python_3=2E2_document_re?=
	=?utf-8?q?fers_to_PEP_382=3A_Defining_a_Stable_ABI?=
In-Reply-To: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>
Message-ID: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

But "Defining a Stable ABI" is PEP 384: http://www.python.org/dev/peps/pep-0384/
(PEP 382 is "Namespace Packages")

----------
assignee: docs at python
components: Documentation
messages: 123345
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: What?s New In Python 3.2 document refers to PEP 382: Defining a Stable ABI
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Dec  4 14:19:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 13:19:31 +0000
Subject: [issue10624] Move requires_IEEE_754 decorator from test_complex into
	test.support
In-Reply-To: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>
Message-ID: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

The decorator could be shared in at least datetimetester, test_cmath, test_complex, test_decimal, test_fractions, test_long, and test_math.

----------
assignee: eric.smith
components: Tests
keywords: easy
messages: 123346
nosy: eric.smith, mark.dickinson
priority: low
severity: normal
status: open
title: Move requires_IEEE_754 decorator from test_complex into test.support
versions: Python 3.2

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

From report at bugs.python.org  Sat Dec  4 14:21:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 13:21:32 +0000
Subject: [issue10624] Move requires_IEEE_754 decorator from test_complex into
	test.support
In-Reply-To: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>
Message-ID: <1291468892.9.0.0970477524085.issue10624@psf.upfronthosting.co.za>


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

+1.

----------

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

From report at bugs.python.org  Sat Dec  4 14:24:32 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 13:24:32 +0000
Subject: [issue10625] There is no test for repr(complex(-0.,
	1.)) special handling
In-Reply-To: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>
Message-ID: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

There's a special test in the C code for this, but there no test for it in test_complex. Note that this needs to be a IEEE 754 specific test.

----------
assignee: eric.smith
components: Tests
keywords: easy
messages: 123348
nosy: eric.smith
priority: normal
severity: normal
status: open
title: There is no test for repr(complex(-0.,1.)) special handling
versions: Python 3.2

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

From report at bugs.python.org  Sat Dec  4 14:32:51 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 13:32:51 +0000
Subject: [issue10624] Move requires_IEEE_754 decorator from test_complex into
	test.support
In-Reply-To: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>
Message-ID: <1291469571.46.0.0232593032822.issue10624@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Moved from test_math.py into support.py in r87040. I'll fix up the other modules shortly.

----------

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

From report at bugs.python.org  Sat Dec  4 14:33:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 13:33:25 +0000
Subject: [issue10625] There is no test for repr(complex(-0.,
	1.)) special handling
In-Reply-To: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>
Message-ID: <1291469605.26.0.436094273362.issue10625@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/issue10625>
_______________________________________

From report at bugs.python.org  Sat Dec  4 14:35:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 13:35:42 +0000
Subject: [issue10625] There is no test for repr(complex(-0.,
	1.)) special handling
In-Reply-To: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>
Message-ID: <1291469742.52.0.22491989288.issue10625@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Technically the special handling in complex_repr() is for +0, but there needs to be a test both ways.

----------

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

From report at bugs.python.org  Sat Dec  4 14:50:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Dec 2010 13:50:17 +0000
Subject: =?utf-8?q?=5Bissue10623=5D_What=E2=80=99s_New_In_Python_3=2E2_document_re?=
	=?utf-8?q?fers_to_PEP_382=3A_Defining_a_Stable_ABI?=
In-Reply-To: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>
Message-ID: <1291470617.19.0.746130586403.issue10623@psf.upfronthosting.co.za>


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

Thanks for the report. Fixed in r87042

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

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

From report at bugs.python.org  Sat Dec  4 14:51:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 13:51:15 +0000
Subject: [issue10626] test_concurrent_futures failure under Windows Server 2008
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>


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

See this buildbot log:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/198/steps/test/logs/stdio

======================================================================
FAIL: test_done_callback_raises (test.test_concurrent_futures.FutureTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 646, in test_done_callback_raises
    self.assertIn('Exception: doh!', logging_stream.getvalue())
AssertionError: 'Exception: doh!' not found in ''

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

----------
assignee: bquinlan
components: Library (Lib), Tests
messages: 123352
nosy: bquinlan, brian.curtin, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures failure under Windows Server 2008
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Dec  4 15:08:00 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 14:08:00 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291471680.1.0.121919939415.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch with the following:

1. list.copy() and list.clear() implemented in Objects/listobject.c, with appropriate doc strings (modeled after dict's docstrings)
2. Same methods implemented in collections.UserList
3. Tests added that exercise the methods in both list and UserList

Re the documentation, it's currently unclear where it should go. I asked on docs at python.org.

----------
Added file: http://bugs.python.org/file19938/issue10516.2.patch

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

From report at bugs.python.org  Sat Dec  4 15:47:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 14:47:01 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1291471680.1.0.121919939415.issue10516@psf.upfronthosting.co.za>
Message-ID: <4CFA545F.9040004@netwok.org>


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

Hi Eli,

I think the right place is 4.6.4,
http://docs.python.org/dev/library/stdtypes#mutable-sequence-types

It starts with ?List and bytearray objects support additional operations
that allow in-place modification of the object?.

For methods not supported by bytearray, you can use the fake footnote
(8) and edit its texte (?sort() is not supported by bytearray objects?).

Regards

----------

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

From report at bugs.python.org  Sat Dec  4 16:02:50 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 04 Dec 2010 15:02:50 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1291474970.53.0.120865755195.issue6490@psf.upfronthosting.co.za>


Changes by Neil Muller <drnlmuller+bugs at gmail.com>:


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

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

From report at bugs.python.org  Sat Dec  4 16:08:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:08:57 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1291475337.1.0.197133746485.issue9523@psf.upfronthosting.co.za>


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

In 3.2, objects return by dbm.dumb.open implement MutableMapping with incorrect semantics: keys return a list, iterkeys exist, etc.

----------

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

From report at bugs.python.org  Sat Dec  4 16:16:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:16:14 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1291475774.61.0.0396510601656.issue10609@psf.upfronthosting.co.za>


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

Arg, the internal classes returned by dbm.*.open have keys but not necessarily items.  See #9523, #6045 and #5736.

The docs should be fixed independently of that, with the less non-idiomatic code that we can find.  Do you want to check the dbm docs for other similar broken examples?  I?ll review the patch.

----------
assignee: docs at python -> eric.araujo

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

From report at bugs.python.org  Sat Dec  4 16:18:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 15:18:49 +0000
Subject: [issue10624] Move requires_IEEE_754 decorator from test_complex into
	test.support
In-Reply-To: <1291468771.13.0.732059095868.issue10624@psf.upfronthosting.co.za>
Message-ID: <1291475929.33.0.995943838689.issue10624@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Modified all other tests to use support.requires_IEEE_754 in r87043.

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

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

From report at bugs.python.org  Sat Dec  4 16:21:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:21:02 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1291476062.87.0.450463687626.issue5736@psf.upfronthosting.co.za>


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

This may be superseded by #9523.  There are comments and patches in both issues, so I?m not closing either as duplicate of the other.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 16:22:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:22:51 +0000
Subject: [issue6045] Add more dict methods to dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1291476171.11.0.228595850007.issue6045@psf.upfronthosting.co.za>


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

See also #9523.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 16:26:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 15:26:42 +0000
Subject: [issue10625] There is no test for repr(complex(-0.,
	1.)) special handling
In-Reply-To: <1291469072.67.0.197064597975.issue10625@psf.upfronthosting.co.za>
Message-ID: <1291476402.22.0.810052175884.issue10625@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked-in in r87044.

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

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

From report at bugs.python.org  Sat Dec  4 16:27:36 2010
From: report at bugs.python.org (Jiri Kulik)
Date: Sat, 04 Dec 2010 15:27:36 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1291476456.36.0.122059742604.issue7936@psf.upfronthosting.co.za>


Jiri Kulik <jiri.kulik at jkulik.eu> added the comment:

Encountered the same issue with 3.1.2 and 3.1.3 64bit on Win7 64bit. I was able to fix it in registry but did so many changes at once that I'm not able to reproduce (was really annoyed after trying to fix it for half a day...). Anyway, sending my observations:

- the root cause seems to be creation of "python.exe" and "pythonw.exe" entries under HKEY_CLASSES_ROOT. Their open command did not have %*. They were not created under HKEY_LOCAL_MACHINE. They were probably created automatically by the system when manually associating py and pyw files (see below).
- .py and .pyw files were originally associated with py_auto_file and pyw_auto_file in HKCR. The associations were probably created by the system, when I manually change association of the .py and .pyw files from jython to python through control panel. The py_auto_file and pyw_auto_files seemed to call those python.exe and pythonw.exe entries in the HKLC.
- The assoc and ftype commands changed association in HKLM but it is not propagated automatically into HKCR, not even after restart. After manually deleting .py and .pyw entries from HKCR, they were replaced by correct entries from HKLM.
- BUT!! the system still called open commands under python.exe and pythonw.exe entries in HKCR! (even if .py was associated with Python.File in HKCR and proper Python.File existed even in HKCR!) Only after deleting them, it works as should. But I deleted a lot of other python related entries as well, so this is only assumption.

If anyone else can confirm that deleting of python.exe and pythonw.exe from HKCR itself corrects the issue, I think the installation program can check if these entries exists and offer to delete them.

Just for complete picture, it works now even with .py and .pyw in PATHEXT, so calling the scripts without extension.

----------
nosy: +jiri.kulik
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Sat Dec  4 16:29:38 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 04 Dec 2010 15:29:38 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1291476578.83.0.659635850459.issue5863@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

I'll try working on a patch.

----------
nosy: +xuanji

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

From report at bugs.python.org  Sat Dec  4 16:31:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:31:14 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1291476674.95.0.374640332029.issue10616@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 16:33:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:33:46 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291476826.88.0.87359589229.issue10621@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19937/unnamed

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

From report at bugs.python.org  Sat Dec  4 16:34:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:34:27 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291476867.34.0.406928503623.issue10621@psf.upfronthosting.co.za>


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

-1 on the change.

Retro: would you mind stop sending HTML email to this tracker?  It creates unnamed attachments that are distracting.  Thanks in advance.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 16:46:14 2010
From: report at bugs.python.org (Jiri Kulik)
Date: Sat, 04 Dec 2010 15:46:14 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1291477574.9.0.468797907113.issue7936@psf.upfronthosting.co.za>


Jiri Kulik <jiri.kulik at jkulik.eu> added the comment:

I'm sorry, I changed version to 3.3 by mistake. Did not want to do it.

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

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

From report at bugs.python.org  Sat Dec  4 16:58:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 15:58:03 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291478283.06.0.985568207206.issue10621@psf.upfronthosting.co.za>


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

Okay, closing as 'wont fix'.

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

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

From report at bugs.python.org  Sat Dec  4 16:58:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 15:58:27 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291478307.65.0.505113870172.issue10621@psf.upfronthosting.co.za>


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


----------
components: +Interpreter Core -IO
type:  -> feature request

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

From report at bugs.python.org  Sat Dec  4 17:02:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 16:02:41 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1291478561.46.0.388675626334.issue3132@psf.upfronthosting.co.za>


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

> Another possibility is to implement the 'O' format unsafely [...]

Hmm.  I don't much like that idea.  Historically, it's supposed to be very difficult to segfault the Python interpreter with pure Python code (well except if you're using ctypes, I guess).

----------

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

From report at bugs.python.org  Sat Dec  4 17:11:06 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 04 Dec 2010 16:11:06 +0000
Subject: [issue10627] Remove usage of deprecated configparser.ConfigParser
	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

configparser.ConfigParser is deprecated as of 3.2 and thus standard library modules should not use that.

The migration path is trivial and should not introduce any compatibility problems whatsoever. All it needs is to switch usage of ConfigParser to SafeConfigParser.

Please find attached a patch that makes the necessary renames.

For the curious, rationale for the deprecation:
- ConfigParser forces interpolation on users, providing no way of escaping interpolation if necessary
- ConfigParser does not check types given on set() and add*() methods, which may lead to invalid internal state (which will raise exceptions when trying to write() configuration or get() values from it)
- until recently configparser's unit tests assumed no instance customization. ConfigParser's error handling is broken when optionxform is overriden

----------
assignee: tarek
components: Distutils, IDLE, Library (Lib)
keywords: needs review, patch
messages: 123367
nosy: eric.araujo, lukasz.langa, tarek
priority: high
severity: normal
stage: patch review
status: open
title: Remove usage of deprecated configparser.ConfigParser class in the stdlib
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Dec  4 17:12:25 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 04 Dec 2010 16:12:25 +0000
Subject: [issue10627] Remove usage of deprecated configparser.ConfigParser
	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1291479145.62.0.898673012983.issue10627@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


Added file: http://bugs.python.org/file19939/issue10627.diff

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

From report at bugs.python.org  Sat Dec  4 17:12:58 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 04 Dec 2010 16:12:58 +0000
Subject: [issue10627] Remove usage of deprecated configparser.ConfigParser
	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1291479178.69.0.15761873525.issue10627@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


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

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

From report at bugs.python.org  Sat Dec  4 17:15:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 16:15:24 +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: <1291479324.8.0.813952406952.issue7245@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed rest of patch in r87045.  Will try to get test_pdb2 in shape and working on all platforms.

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

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

From report at bugs.python.org  Sat Dec  4 17:51:34 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 04 Dec 2010 16:51:34 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291478307.68.0.381272806597.issue10621@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=FyB35FJZreiwM=F67mPSWuVJQo3d0HnUA=BSQ@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Do you ever fix anything?

----------
Added file: http://bugs.python.org/file19940/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10621>
_______________________________________
-------------- next part --------------
Do you ever fix anything?

From report at bugs.python.org  Sat Dec  4 18:00:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 17:00:09 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1291482009.88.0.425253432856.issue6210@psf.upfronthosting.co.za>


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

It is not possible to do this using a method, since "raise exc" will add a context anyway. So, if this is desired, it needs some new syntax and should be discussed on python-ideas.

(I don't think this is very important personally. Tracebacks are for developers to look at and I don't think the added information is confusing or detrimental)

----------
assignee: pitrou -> 

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

From report at bugs.python.org  Sat Dec  4 18:09:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 04 Dec 2010 17:09:37 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291482577.04.0.917099659483.issue10621@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19940/unnamed

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

From report at bugs.python.org  Sat Dec  4 18:18:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Dec 2010 17:18:16 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1291483096.0.0.487912052165.issue6210@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To get back to my original objection, it shouldn't be that difficult to differentiate between "__context__ never set" and "__context__ explicitly suppressed".

(e.g. using a property that sets an internal flag when set from Python code or via PyObject_SetAttr, or else a special ExceptionContextSuppressed singleton).

BaseException could then be given a "no_context" class method that did whatever dancing was necessary to suppress the context.

So Steven's examples would become:
def process(iterable):
    try:
        x = next(iterable)
    except StopIteration:
        raise ValueError.no_context("can't process empty iterable")
    continue_processing()

def func(x):
    try:
        x + 0
    except (ValueError, TypeError):
        raise MyException.no_context('x is not a number')
    do_something_with(x)

With appropriate changes to the exception display code, no_context could be as simple as the C equivalent of the following:

@classmethod
def no_context(cls, *args, **kwds):
  exc = cls(*args, **kwds)
  exc.__context__ = ExceptionContextSuppressed
  return exc

Another alternative would be an additional internal flag queried by the exception chaining code itself:

@classmethod
def no_context(cls, *args, **kwds):
  exc = cls(*args, **kwds)
  exc.__context__ = None
  exc._add_context = False
  return exc

----------

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

From report at bugs.python.org  Sat Dec  4 18:20:58 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 04 Dec 2010 17:20:58 +0000
Subject: [issue10627] Remove usage of deprecated configparser.ConfigParser
	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1291483258.85.0.502098173461.issue10627@psf.upfronthosting.co.za>


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

So, as discussed w/ Lukasz:

- distutils1 gets unchanged and the warning is silenced there
- distutils2 uses SafeConfigParser [done]

----------

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

From report at bugs.python.org  Sat Dec  4 18:22:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 17:22:19 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1291483339.08.0.0210537176344.issue4391@psf.upfronthosting.co.za>


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

Attached patch fixes the two misuses I found in argparse.

I tried importing ngettext as _ngettext to comply with arpgarse?s crazy^Wpersonal <wink> import style (enforced in TestImportStar), but then I could not force xgettext to find all the strings.  Rather than struggle longer with the program, I chose to add an exception for ngettext in the test.  ?from argparse import *? does not import ngettext, thanks to __all__, so I think my choice is simple and sensible.

----------
title: optparse: use proper gettext plurals forms -> use proper gettext plurals forms in argparse and optparse
Added file: http://bugs.python.org/file19941/fix-argparse-ngettext.diff

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

From report at bugs.python.org  Sat Dec  4 18:25:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Dec 2010 17:25:52 +0000
Subject: [issue10601] sys.displayhook: use backslashreplace error handler if
	repr(value) is not encodable to sys.stdout
In-Reply-To: <1291254207.25.0.743173639978.issue10601@psf.upfronthosting.co.za>
Message-ID: <1291483552.32.0.896584563468.issue10601@psf.upfronthosting.co.za>


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

Commited to Python 3.2 (r87054).

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

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

From report at bugs.python.org  Sat Dec  4 18:26:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 17:26:16 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1291483576.38.0.425236978228.issue4391@psf.upfronthosting.co.za>


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

Georg approved my patch for the beta1.  Steven, since you approved my other gettext-related changes, we thing it?s okay if I don?t wait for your +1.

For optparse, I will review the changes later.

----------
assignee:  -> eric.araujo

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

From report at bugs.python.org  Sat Dec  4 18:29:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 04 Dec 2010 17:29:51 +0000
Subject: [issue7110] Output test failures on stderr in regrtest.py
In-Reply-To: <1255334934.67.0.943013773261.issue7110@psf.upfronthosting.co.za>
Message-ID: <1291483791.06.0.613738501167.issue7110@psf.upfronthosting.co.za>


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

I've decided that writing (some) errors to stdout instead of stderr is really a bug, not a feature request, and have backported this fix to 3.1 in r87053 and to 2.7 in r87055.

The one possible reason not to do this is that it is conceivable that it would affect the error reporting from an automated acceptance test (say for a distro).  This seems unlikely to me, but if anyone thinks it is a serious concern I'll back out the backports.

----------
nosy: +Arfrever, barry, doko
type: feature request -> behavior

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

From report at bugs.python.org  Sat Dec  4 18:32:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 17:32:59 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1291483979.28.0.129563320361.issue4391@psf.upfronthosting.co.za>


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

Revision 87056

----------

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

From report at bugs.python.org  Sat Dec  4 18:37:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 17:37:52 +0000
Subject: [issue10627] Remove usage of deprecated configparser.ConfigParser
	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1291484272.18.0.840809263518.issue10627@psf.upfronthosting.co.za>


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

I?ve changed d2 to use RawConfigParser six months ago: http://bitbucket.org/tarek/distutils2/changeset/e2a1113b5572

I don?t think we need the interpolation provided by SafeConfigParser.

----------

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

From report at bugs.python.org  Sat Dec  4 18:41:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 17:41:10 +0000
Subject: [issue10621] >>> 1 + 2j --> (1 + 2j) and not (1+2j)
In-Reply-To: <1291454509.87.0.00219292943169.issue10621@psf.upfronthosting.co.za>
Message-ID: <1291484470.85.0.71655356122.issue10621@psf.upfronthosting.co.za>


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

Not much: http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=2&%40columns=status&resolution=3&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search

----------

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

From report at bugs.python.org  Sat Dec  4 18:55:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 17:55:48 +0000
Subject: [issue10553] Add optimize argument to builtin compile() and
	byte-compilation modules
In-Reply-To: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>
Message-ID: <1291485348.04.0.692461167693.issue10553@psf.upfronthosting.co.za>


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

As discussed on IRC, compileall had not gained a new command-line argument because ?python -O -m compileall? does the job.  Can I make a doc update for that, or do you think it may be obvious enough?

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec  4 18:56:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 04 Dec 2010 17:56:45 +0000
Subject: [issue10553] Add optimize argument to builtin compile() and
	byte-compilation modules
In-Reply-To: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>
Message-ID: <1291485405.83.0.424912065908.issue10553@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, a doc update is probably a good idea.  (But after the freeze :)

----------

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

From report at bugs.python.org  Sat Dec  4 19:18:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 18:18:03 +0000
Subject: [issue10553] Add optimize argument to builtin compile() and
	byte-compilation modules
In-Reply-To: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>
Message-ID: <1291486683.96.0.466016206957.issue10553@psf.upfronthosting.co.za>


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

Temporarily reopening.

----------
assignee:  -> eric.araujo
status: closed -> open

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

From report at bugs.python.org  Sat Dec  4 19:50:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Dec 2010 18:50:09 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291488609.35.0.0135824320237.issue10516@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger
keywords: +easy -patch

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

From report at bugs.python.org  Sat Dec  4 20:10:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 19:10:55 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

See patch.

----------
assignee: rhettinger
components: Documentation
files: whatsnew-3.2-typos.diff
keywords: patch
messages: 123383
nosy: eric.araujo, rhettinger
priority: normal
severity: normal
status: open
title: Typos in 3.2 what?s new
versions: Python 3.2
Added file: http://bugs.python.org/file19942/whatsnew-3.2-typos.diff

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

From report at bugs.python.org  Sat Dec  4 20:23:15 2010
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Sat, 04 Dec 2010 19:23:15 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1291490595.98.0.0588146309489.issue6101@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

Maybe I am missing something, but why was it ok for this patch to move EXTENDED_ARGS from 143 to 145 ? I thought the numbers for opcodes were part of the ABI ?

----------
nosy: +thomasvs

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

From report at bugs.python.org  Sat Dec  4 20:26:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 04 Dec 2010 19:26:12 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1291490595.98.0.0588146309489.issue6101@psf.upfronthosting.co.za>
Message-ID: <AANLkTimXr-yBA=H4=R9N9tsM1ds6gGwwr6AeA4t4-Mvc@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/12/4 Thomas Vander Stichele <report at bugs.python.org>:
>
> Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:
>
> Maybe I am missing something, but why was it ok for this patch to move EXTENDED_ARGS from 143 to 145 ? I thought the numbers for opcodes were part of the ABI ?

Very much not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:26:33 2010
From: report at bugs.python.org (Johann Hanne)
Date: Sat, 04 Dec 2010 19:26:33 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291490793.15.0.159090265787.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

>Will it then also link something?

Sure - it actually builds a python.exe which is fully working for me. If you need a proof, please let me know, I have no problem uploading it somewhere...

Is there a reason you are so sceptical? After all, Python for Linux is also usually compiled with gcc, so why shouldn't it work for Win32?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:28:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 19:28:48 +0000
Subject: [issue10626] test_concurrent_futures failure
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291490928.63.0.381039395595.issue10626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same one under Ubuntu:
http://www.python.org/dev/buildbot/all/builders/PPC64%20Ubuntu%203.x/builds/265/steps/test/logs/stdio

----------
title: test_concurrent_futures failure under Windows Server 2008 -> test_concurrent_futures failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:31:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 04 Dec 2010 19:31:48 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1291460599.21.0.736219181329.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTikJA1uxZTvKHJnRGjwYFq90tdfrkSV6GXpNswVE@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Dec 4, 2010 at 6:03 AM, Mark Dickinson <report at bugs.python.org> wrote:
..
> I don't much like the extra boilerplate that's introduced (and repeated)
> in longobject.c, floatobject.c and complexobject.c, though.
>

Yes, that's exactly what I meant when I called that code
"repetitious."  Maybe we can tighten this up during the beta period.
What do you think about adding number parsers that operate directly on
Py_UNICODE* strings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:33:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 19:33:40 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291491220.12.0.320440784799.issue10615@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:42:21 2010
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Sat, 04 Dec 2010 19:42:21 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1291491741.32.0.562224126999.issue6101@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

Really ? Is this documented somewhere ? Do you know of any other case where a number for an existing opcode was changed ? I can't find any so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:44:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 19:44:48 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1291491741.32.0.562224126999.issue6101@psf.upfronthosting.co.za>
Message-ID: <1291491884.3534.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Really ? Is this documented somewhere ? Do you know of any other case
> where a number for an existing opcode was changed ? I can't find any
> so far.

Opcodes are an implementation detail. If you are fiddling with opcodes,
how will your code work under Jython, IronPython or even PyPy?
Besides, not only opcode numbers may change, but the semantics of a
given opcode can change too (even if its number stays the same). So
there's nothing stable you can rely on here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:47:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Dec 2010 19:47:34 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291490793.15.0.159090265787.issue10615@psf.upfronthosting.co.za>
Message-ID: <4CFA9AD4.3000709@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Sure - it actually builds a python.exe which is fully working for me. If you need a proof, please let me know, I have no problem uploading it somewhere...
> 
> Is there a reason you are so sceptical? After all, Python for Linux is also usually compiled with gcc, so why shouldn't it work for Win32?

There is a long track of people contributing patches to Python saying
"you need this and that to make it work on platform XYZ". Right after
accepting these patches (without testing, because we might not have
access to XYZ) they come back with more patches. If you then look
carefully at the initial submission, they never actually claimed that
this is *all* patches that are needed. Instead, they use phrases like
"some trivial fixes" (meaning that the difficult fixes are yet to come).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:47:37 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 04 Dec 2010 19:47:37 +0000
Subject: [issue10626] test_concurrent_futures failure
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291492057.36.0.649091625844.issue10626@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Possibly related: issue #10517.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:49:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 19:49:50 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1291492190.32.0.143228175876.issue10562@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19929/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:51:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 19:51:59 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1291492319.77.0.0992220028546.issue10618@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10618>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:55:27 2010
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Sat, 04 Dec 2010 19:55:27 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1291492527.99.0.0512230477023.issue6101@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

Well, I just checked, and from 2.3 to 2.6 opcodes were only added, existing ones were never renumbered.

2.7 however reshuffled a bunch of them, for no apparent reason at all:

$ diff -au opcodes-2.6 opcodes-2.7
--- opcodes-2.6	2010-12-04 20:47:19.110031279 +0100
+++ opcodes-2.7	2010-12-04 20:47:06.770611299 +0100
@@ -10,7 +10,6 @@
   12 UNARY_NOT
   13 UNARY_CONVERT
   15 UNARY_INVERT
-  18 LIST_APPEND
   19 BINARY_POWER
   20 BINARY_MULTIPLY
   21 BINARY_DIVIDE
@@ -73,6 +72,7 @@
   91 DELETE_NAME
   92 UNPACK_SEQUENCE
   93 FOR_ITER
+  94 LIST_APPEND
   95 STORE_ATTR
   96 DELETE_ATTR
   97 STORE_GLOBAL
@@ -82,15 +82,18 @@
  101 LOAD_NAME
  102 BUILD_TUPLE
  103 BUILD_LIST
- 104 BUILD_MAP
- 105 LOAD_ATTR
- 106 COMPARE_OP
- 107 IMPORT_NAME
- 108 IMPORT_FROM
+ 104 BUILD_SET
+ 105 BUILD_MAP
+ 106 LOAD_ATTR
+ 107 COMPARE_OP
+ 108 IMPORT_NAME
+ 109 IMPORT_FROM
  110 JUMP_FORWARD
- 111 JUMP_IF_FALSE
- 112 JUMP_IF_TRUE
+ 111 JUMP_IF_FALSE_OR_POP
+ 112 JUMP_IF_TRUE_OR_POP
  113 JUMP_ABSOLUTE
+ 114 POP_JUMP_IF_FALSE
+ 115 POP_JUMP_IF_TRUE
  116 LOAD_GLOBAL
  119 CONTINUE_LOOP
  120 SETUP_LOOP
@@ -110,4 +113,7 @@
  140 CALL_FUNCTION_VAR
  141 CALL_FUNCTION_KW
  142 CALL_FUNCTION_VAR_KW
- 143 EXTENDED_ARG
+ 143 SETUP_WITH
+ 145 EXTENDED_ARG
+ 146 SET_ADD
+ 147 MAP_ADD

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Sat Dec  4 20:58:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 19:58:56 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1291492527.99.0.0512230477023.issue6101@psf.upfronthosting.co.za>
Message-ID: <1291492732.3534.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, I just checked, and from 2.3 to 2.6 opcodes were only added,
> existing ones were never renumbered.
> 
> 2.7 however reshuffled a bunch of them, for no apparent reason at all:

LIST_APPEND was renumbered because it gained an argument.
There are also new opcodes in this list.
Regardless, there is no guarantee about opcode numbering stability. You
cannot infer such an expectation from previous behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:01:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Dec 2010 20:01:19 +0000
Subject: [issue6101] SETUP_WITH
In-Reply-To: <1243207897.72.0.986080624024.issue6101@psf.upfronthosting.co.za>
Message-ID: <1291492879.46.0.0977001153237.issue6101@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Yes, someone went nuts with renumbering.  That is allowed but was probably unnecessary.

That being said, users of opcodes should really use the names in opcode.py instead of the numbers themselves.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6101>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:04:00 2010
From: report at bugs.python.org (Johann Hanne)
Date: Sat, 04 Dec 2010 20:04:00 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291493040.53.0.877788804226.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

Ok, I see. And no, this is *not* my intention. I will post the list of successfully compiled objects files and the linker result on Monday as promised. If it turns out I lied, feel free to put me into the hall of shame.

After all, the Win32 platform is not that uncommon. I know, MinGW could be seen as a different platform, but I never encountered a situation where I required anything but the exe file (no special MinGW DLL or something like that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:06:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Dec 2010 20:06:53 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291493040.53.0.877788804226.issue10615@psf.upfronthosting.co.za>
Message-ID: <4CFA9F5B.8090808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> After all, the Win32 platform is not that uncommon. I know, MinGW
> could be seen as a different platform, but I never encountered a
> situation where I required anything but the exe file (no special
> MinGW DLL or something like that).

Traditionally, MingW-compiled Python binaries would often be
binary-incompatible with the ones available from python.org, since the
MingW build would use a different version of the MS CRT than the
python.org version. As a consequence, extensions built for the official
binaries would crash in the MingW build, and vice versa.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:11:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Dec 2010 20:11:56 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291493516.72.0.216748407371.issue10557@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> What do you think about adding number parsers that operate directly on
> Py_UNICODE* strings?

I think that might make some sense.  It's not without difficulties, though.  One issue is that we'd still need the char* -> double operations, partly because PyOS_string_to_double is part of the public API, and partly to continue to support creation of a float from a bytes instance.

The other issue is that for floats, it's difficult to separate the parser from the base conversion;  to be useful, we'd probably end up making the whole of dtoa.c Py_UNICODE aware.  (One of the return values from the dtoa.c parser is a pointer to the significant digits in the original input string;  so the base-conversion calculation itself needs access to portions of the original string.)

Ideally, for float(string), we'd have a zero-copy setup that operated directly on the unicode input (read-only);  but I think that achieving that right now is going to be messy, and involve dtoa.c knowing far more about Unicode that I'd be comfortable with.

N.B. If we didn't have to deal with alternative digits, it *really* would be much simpler.

Perhaps a compromise option is available, that does a preliminary pass on the Unicode string and only makes a copy if non-European digits are discovered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:27:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Dec 2010 20:27:25 +0000
Subject: [issue10626] test_concurrent_futures failure
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291494445.87.0.851679948413.issue10626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Minimal command line for reproducing:

./python -m test -uall test_pydoc test_logging test_concurrent_futures
[1/3] test_pydoc
[46429 refs]
[46430 refs]
[46430 refs]
[46429 refs]
[46430 refs]
[46425 refs]
[46425 refs]
[2/3] test_logging
[3/3] test_concurrent_futures
test test_concurrent_futures failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_concurrent_futures.py", line 646, in test_done_callback_raises
    self.assertIn('Exception: doh!', logging_stream.getvalue())
AssertionError: 'Exception: doh!' not found in ''


And the culprint seems to be r86962:

user:        nick.coghlan
date:        Fri Dec 03 10:29:11 2010 +0100
summary:     [svn r86962] Improve Pydoc interactive browsing (#2001).  Patch by Ron Adam.

----------
assignee: bquinlan -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:38:43 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 20:38:43 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291495123.85.0.510389173027.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Following ?ric's suggestion, I'm attaching an updated patch with with the documentation in Doc/library/stdtypes.rst updated with the new methods.

There seems to be a slight Sphinx markup problem with this addition. I rewrote note (8) as:

   :meth:`clear`, :meth:`copy` and :meth:`sort` are not supported by
   :class:`bytearray` objects.

Unfortunately, :meth:`copy` is getting linked to the copy module.

----------
keywords: +patch
Added file: http://bugs.python.org/file19943/issue10516.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:39:58 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 20:39:58 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291495198.69.0.111779210323.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19835/issue10516.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:40:02 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 04 Dec 2010 20:40:02 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291495202.53.0.155119117043.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19938/issue10516.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:44:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 04 Dec 2010 20:44:21 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291495461.05.0.251213302119.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Nothing will happen on this until 3.2 is done and the py3k branch starts with 3.3 submissions.

----------
resolution:  -> later

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Dec  4 21:48:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 20:48:42 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291495722.9.0.539369157753.issue10516@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Eli, I learned this trick recently: :meth:`!copy`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Dec  4 22:03:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 04 Dec 2010 21:03:19 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1291493516.72.0.216748407371.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=BjOg2-LdrPp6fiGin9SE89ST+J92o2Q4sof5u@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Dec 4, 2010 at 3:11 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>.. One issue is that we'd still need the char* -> double operations, partly because
> PyOS_string_to_double is part of the public API, and partly to continue to support
> creation of a float from a bytes instance.
>

I thought about it.  I see two solutions:

1. Retain PyOS_string_to_double unchanged and add PyOS_unicode_to_double.
2. Replace PyOS_string_to_double with UTF-8 decode result passed to
PyOS_unicode_to_double.

> The other issue is that for floats, it's difficult to separate the parser from the base
> conversion; ?to be useful, we'd probably end up making the whole of dtoa.c
> Py_UNICODE aware.

That's what I had in mind.  Naively it looks like we just need to
replace char type with Py_UNICODE in several places.  Assuming exotic
digit conversion is still handled separately.

> ?(One of the return values from the dtoa.c parser is a pointer to the significant digits
> in the original input string; ?so the base-conversion calculation itself needs access
> to portions of the original string.)
>

Maybe we should start with int().  It is simpler, but probably reveal
some of the same difficulties as float()

> Ideally, for float(string), we'd have a zero-copy setup that operated directly on the
> unicode input (read-only); ?but I think that achieving that right now is going to be
> messy, and involve dtoa.c knowing far more about Unicode that I'd be comfortable
> with.
>

This is clearly a 3.3-ish project.  Hopefully in time people will
realize that decimal digits are just [0-9] and numeric experts will
not be required to know about Unicode beyond 127th code point. :-)

> N.B. If we didn't have to deal with alternative digits, it *really* would be much simpler.
>

We still don't.  I've already separated this out and we can keep it
this way as long as people are willing to pay the price for
alternative digits' support.

One thing we may improve, is to fail earlier on non-digits in
PyUnicode_TransformDecimalToASCII()  to speedup not uncommon code like
this:

for line in f:
   try:
       n = int(lint)
   except ValueError:
       pass
   ...

> Perhaps a compromise option is available, that does a preliminary pass on the
> Unicode string and only makes a copy if non-European digits are discovered.

Hmm.  That would require changing the signature of
PyUnicode_TransformDecimalToASCII() to take PyObject* instead of the
buffer.  I knew we shouldn't have rushed to make it public.  We can
still do it in longobject.c and friends' boilerplate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sat Dec  4 22:04:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 04 Dec 2010 21:04:05 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291496645.36.0.43049636837.issue10615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> As a consequence, extensions built for the official
> binaries would crash in the MingW build, and vice versa

IMO this is a use case for the new "soabi" tag...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 22:23:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 04 Dec 2010 21:23:49 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291497829.14.0.568769526256.issue10615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Sure - it actually builds a python.exe which is fully working for me.
> If you need a proof, please let me know, I have no problem uploading
> it somewhere...

This is useless, of course.  The build must be reproducible.
Here is what I did so far:

- Open a cmd.exe console, ensure that msys/bin and mingw/bin are in the PATH
- Run "sh configure" - it's slow, but works.
- Run "make"
- Re-running "make -k" fails on three files: import.c, posixmodule.c, and pwdmodule.c

Your patch does not touch import.c, and the pwd module should probably be removed from a Python running on Windows.
Do you use another method to compile Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sat Dec  4 23:41:09 2010
From: report at bugs.python.org (Martin Budaj)
Date: Sat, 04 Dec 2010 22:41:09 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1291502469.04.0.651451617673.issue10515@psf.upfronthosting.co.za>


Martin Budaj <m.budaj at gmail.com> added the comment:

I'm not sure about what the intended behavior for testAl should be, however I think that the file should be recognized as having one column of data and no delimiter (there is a test for this case in csv.py) and not raise an exception.

I attach patch for test_csv.py tests. It includes two more tests which currently fail (both contain \r\n as a newline)

----------
Added file: http://bugs.python.org/file19944/test_csv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sat Dec  4 23:59:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Dec 2010 22:59:55 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291496645.36.0.43049636837.issue10615@psf.upfronthosting.co.za>
Message-ID: <4CFAC7E8.2000506@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> IMO this is a use case for the new "soabi" tag...

Unfortunately not: these tags are not supported on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sun Dec  5 00:15:01 2010
From: report at bugs.python.org (Paul Moore)
Date: Sat, 04 Dec 2010 23:15:01 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1291504501.86.0.656498183639.issue7213@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

This bug appears to be Unix-only. On Windows:

>>> from subprocess import *
>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE)
>>> p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE)
>>> p1.stdin.write("aaaaaaaaaaaaaaaa\n")
>>> p1.stdin.close()
>>> p2.stdout.read()
'aaaaaaaaaaaaaaaa\n'
>>>

So there's no clear reason why the default should change on Windows. (It's not possible to specify close_fds explicitly on Windows for this case:

>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE, close_fds=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Apps\Python27\lib\subprocess.py", line 630, in __init__
    raise ValueError("close_fds is not supported on Windows "
ValueError: close_fds is not supported on Windows platforms if you redirect stdin/stdout/stderr

which may imply that False is not only reasonable, but necessary on Windows. I haven't dug into this enough to know for sure if this is the case, though).

----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sun Dec  5 00:34:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 04 Dec 2010 23:34:39 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291505679.96.0.805116368584.issue10615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > IMO this is a use case for the new "soabi" tag...
> Unfortunately not: these tags are not supported on Windows.
So it's a argument for adding (optional?) soabi tags on Windows!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Sun Dec  5 02:37:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 01:37:15 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1291513035.48.0.403806040015.issue10197@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The question that remains is, does removing the {} change the output
> obtained from a command sequence in any way?
{} are used to group output from the commands into one stream.  I believe the stdout and stderr arguments to Popen allow us to get compatible behavior.  Tests need to prove that, of course.

> Which makes me wonder if getoutput/getstatusoutput should just be
> documentationally deprecated instead.  (I never use them myself, FWIW)
They were relocated from the commands module, resulting in slightly overlapping functions that don?t share a naming patter: call, check_call, getoutput, getstatusoutput.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Sun Dec  5 05:19:41 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 05 Dec 2010 04:19:41 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291522781.48.0.0371319490336.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric - thanks, it works [attaching updated patch]. However, don't you think the core problem is a Sphinx bug we should report?

Raymond - this happens after final 3.2 release (on Feb 05 2011 if it's on schedule), right?

----------
Added file: http://bugs.python.org/file19945/issue10516.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sun Dec  5 05:20:03 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 05 Dec 2010 04:20:03 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291522803.02.0.415156162442.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19943/issue10516.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sun Dec  5 08:59:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Dec 2010 07:59:55 +0000
Subject: =?utf-8?q?=5Bissue10628=5D_Typos_in_3=2E2_what=E2=80=99s_new?=
In-Reply-To: <1291489855.52.0.016822369266.issue10628@psf.upfronthosting.co.za>
Message-ID: <1291535995.47.0.700761863405.issue10628@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied rest in r87083.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10628>
_______________________________________

From report at bugs.python.org  Sun Dec  5 09:18:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Dec 2010 08:18:36 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291537116.29.0.978825898635.issue10626@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is unrelated to issue 10517 (based on Dave Malcolm's initial investigation, that looks like it may be a genuine problem in multiprocessing)

Instead, this relates to a problem in concurrent.futures where it installs a logging *handler* as a side effect of import. IMO, this is itself a bug in the concurrent.futures package - the standard library shouldn't be installing logging handlers implicitly, but only when explicitly asked to do so, or when absolutely necessary (multiprocessing is an example of a package that walks this line appropriately).

The reason the test_pydoc, test_logging, test_concurrent_futures sequence causes an error is as follows:

1. test_pydoc walks the entire package hierarchy when testing its ability to generate the HTML for the search page.
2. this implicitly imports concurrent.futures, since it is implemented as a package that imports names from submodules in __init__.py
3. this means the c.f handler is already registered in logging when test_logging is run
4. as test_logging assumes it has full control over the logging state, the c.f handler is not left in the same state as it started in
5. test_concurrent_futures then fails, as it assumes the state of the handler has not changed since it was created as a side-effect of the package import

Quite a trip down the rabbit hole to figure that one out :)

Handing back to Brian to fix the underlying problem (i.e. the implicit installation of the logging handler by concurrent.futures).

Georg FYI as to why the py3k buildbots will sometimes go red if the randomised execution happens to run these 3 tests in this particular order (and my apologies for checking in the regrtest.py changes during the release freeze).

----------
assignee: ncoghlan -> bquinlan
keywords: +buildbot
nosy: +georg.brandl
title: test_concurrent_futures failure -> test_concurrent_futures implicitly installs a logging handler on import

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Sun Dec  5 09:43:16 2010
From: report at bugs.python.org (Bill McEachen)
Date: Sun, 05 Dec 2010 08:43:16 +0000
Subject: [issue10629] Arbitrary precision
In-Reply-To: <1291538596.71.0.765304275074.issue10629@psf.upfronthosting.co.za>
Message-ID: <1291538596.71.0.765304275074.issue10629@psf.upfronthosting.co.za>


New submission from Bill McEachen <billymac00 at excite.com>:

from this link [http://en.wikipedia.org/wiki/PARI/GP#Usage_examples], I wanted to contrast arbitrary precision with the other pgm I use, Pari/GP.  I tried the xample there which was:
123456! + 0.
Now, behavior seems the same without the "+0." for both.  However, while Pari returns the answer shown on link quickly, Python after a delay returned an error, related to float conversion.  Here is the progression from a smaller number to the problem:
>>> math.factorial(12) +0.
479001600.0
>>> math.factorial(123) +0.
1.214630436702533e+205
>>> math.factorial(1234) +0.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float
>>>

----------
components: Regular Expressions
messages: 123414
nosy: billymac00
priority: normal
severity: normal
status: open
title: Arbitrary precision
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10629>
_______________________________________

From report at bugs.python.org  Sun Dec  5 09:45:05 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 05 Dec 2010 08:45:05 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291538705.05.0.756433387491.issue10576@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is a third patch.  The callback now gets two argument, phase and info.
I've added documentation and unittests.

----------
Added file: http://bugs.python.org/file19946/gccallback3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Sun Dec  5 11:08:34 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 05 Dec 2010 10:08:34 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1291522803.06.0.475734496855.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTim=n4aRr1dgQQ5ZRc6TvaUXfTHpDxPUghLuuokd@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I'm troubled with one little letter:

"L.copy() -> list -- a shallow copy of L");  should be

"L.copy() -> list -- shallow copy of L");  without the letter 'a',
because other sentences also don't say  "L.__sizeof__() -- *A* size of
L in memory, in bytes");

Please fix this.

----------
Added file: http://bugs.python.org/file19947/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
I&#39;m troubled with one little letter:<div><span class="Apple-style-span" style="font-family: &#39;Times New Roman&#39;; font-size: medium; "><pre style="word-wrap: break-word; white-space: pre-wrap; ">&quot;L.copy() -&gt; list -- a shallow copy of L&quot;);  should be</pre>
<pre style="word-wrap: break-word; white-space: pre-wrap; "><span class="Apple-style-span" style="font-family: &#39;Times New Roman&#39;; white-space: normal; "><pre style="word-wrap: break-word; white-space: pre-wrap; ">
&quot;L.copy() -&gt; list -- shallow copy of L&quot;);  without the letter &#39;a&#39;, because other sentences also don&#39;t say  &quot;L.__sizeof__() -- *A* size of L in memory, in bytes&quot;);</pre><pre style="word-wrap: break-word; white-space: pre-wrap; ">
Please fix this.</pre></span></pre></span></div>

From report at bugs.python.org  Sun Dec  5 11:15:56 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 05 Dec 2010 10:15:56 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <AANLkTim=n4aRr1dgQQ5ZRc6TvaUXfTHpDxPUghLuuokd@mail.gmail.com>
Message-ID: <AANLkTikXD_qvjJu5Yeua_6675h-JTpawoT=oV7dSrVE2@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Can you please help me find the definition of the copy() method of dict in
the Python sources? I want to see how that method is defined and compare the
definition to the one in Eli's patch.

----------
Added file: http://bugs.python.org/file19948/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
Can you please help me find the definition of the copy() method of dict in the Python sources? I want to see how that method is defined and compare the definition to the one in Eli&#39;s patch.

From report at bugs.python.org  Sun Dec  5 11:25:47 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 05 Dec 2010 10:25:47 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1291544747.64.0.87049684299.issue4391@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The workaround in TestImportStar is fine. The test is really just meant to make sure that __all__ contains all the current API methods, and the "_" checks were the easiest way at the time to check that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sun Dec  5 13:12:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Dec 2010 12:12:22 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291551142.13.0.489450256246.issue10626@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What a nice mess :)  Raising priority so that this doesn't get overlooked.

----------
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Sun Dec  5 13:15:57 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 05 Dec 2010 12:15:57 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1291551357.59.0.85718734705.issue1294232@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> What also worries me is the difference between the "class"
> statement and the type() function.

I think the reason of this is that the class statement uses the __build_class__ builtin function. This function determines the metaclass to use (by getting the metaclass of the first base class), and calls it. When one directly calls type, one doesn't call the metaclass (though type.__new__ will later call the "real" metaclass).

An example:

>>> class M_A(type):
...     def __new__(mcls, name, bases, ns):
...             print('M_A.__new__', mcls, name, bases)
...             return super().__new__(mcls, name, bases, ns)
...
>>> class M_B(M_A):
...     def __new__(mcls, name, bases, ns):
...             print('M_B.__new__', mcls, name, bases)
...             return super().__new__(mcls, name, bases, ns)
...
>>> class A(metaclass=M_A): pass
...
M_A.__new__ <class '__main__.M_A'> A ()
>>>
>>> class B(metaclass=M_B): pass
...
M_B.__new__ <class '__main__.M_B'> B ()
M_A.__new__ <class '__main__.M_B'> B ()
>>>
>>>
>>> class C(A, B): pass
...
M_A.__new__ <class '__main__.M_A'> C (<class '__main__.A'>, <class '__main__.B'>)
M_B.__new__ <class '__main__.M_B'> C (<class '__main__.A'>, <class '__main__.B'>)
M_A.__new__ <class '__main__.M_B'> C (<class '__main__.A'>, <class '__main__.B'>)
>>>

Above __build_class__ calls M_A (because that is the metaclass of the first base class, A). Then M_A calls type.__new__ with super(), then type.__new__ searches the "real" metaclass, M_B, and calls its __new__. Then M_B.__new__ calls again M_A.__new__.

>>> D = type('D', (A, B), {})
M_B.__new__ <class '__main__.M_B'> D (<class '__main__.A'>, <class '__main__.B'>)
M_A.__new__ <class '__main__.M_B'> D (<class '__main__.A'>, <class '__main__.B'>)
>>>

Above type.__call__ directly calls type.__new__, which determines the "real" metaclass, M_B, and calls it (which then class M_A):

>>> class C2(B, A): pass
...
M_B.__new__ <class '__main__.M_B'> C2 (<class '__main__.B'>, <class '__main__.A'>)
M_A.__new__ <class '__main__.M_B'> C2 (<class '__main__.B'>, <class '__main__.A'>)
>>>

If we reverse the order of the base classes of C (as above for C2), __build_class__ will use M_B as the metaclass.

>>> D2 = M_B('D', (A, B), {})
M_B.__new__ <class '__main__.M_B'> D (<class '__main__.A'>, <class '__main__.B'>)
M_A.__new__ <class '__main__.M_B'> D (<class '__main__.A'>, <class '__main__.B'>)
>>>

And of course, if we call directly the "real" metaclass, M_B (as above), we get the same result.

I used the expression "real metaclass" with the meaning "the __class__ of the class we are currently creating":

>>> C.__class__
<class '__main__.M_B'>
>>> C2.__class__
<class '__main__.M_B'>
>>> D.__class__
<class '__main__.M_B'>
>>> D2.__class__
<class '__main__.M_B'>

Summary: the problem seems to be, that __build_class__ doesn't call the "real" metaclass, but the metaclass of the first base. (Note: I think this is approximately consistent with the documentation: "Otherwise, if there is at least one base class, its metaclass is used." But I don't know, if this is the desired behaviour.)

This behaviour of __build_class__ can result in problems. For example, if the two metaclasses define __prepare__. In some cases __build_class__ won't call the "real" metaclass' __prepare__, but the other's:

>>> class M_A(type):
...     def __new__(mcls, name, bases, ns):
...             print('M_A.__new__', mcls, name, bases)
...             return super().__new__(mcls, name, bases, ns)
...     @classmethod
...     def __prepare__(mcls, name, bases):
...             print('M_A.__prepare__', mcls, name, bases)
...             return {}
...
>>> class M_B(M_A):
...     def __new__(mcls, name, bases, ns):
...             print('M_B.__new__', mcls, name, bases, ns)
...             return super().__new__(mcls, name, bases, ns)
...     @classmethod
...     def __prepare__(mcls, name, bases):
...             print('M_B.__prepare__', mcls, name, bases)
...             return {'M_B_was_here': True}
...

The __prepare__ method of the two metaclass differs, M_B leaves a 'M_B_was_here' name in the namespace.

>>> class A(metaclass=M_A): pass
...
M_A.__prepare__ <class '__main__.M_A'> A ()
M_A.__new__ <class '__main__.M_A'> A ()
>>>
>>> class B(metaclass=M_B): pass
...
M_B.__prepare__ <class '__main__.M_B'> B ()
M_B.__new__ <class '__main__.M_B'> B () {'M_B_was_here': True, '__module__': '__main__'}
M_A.__new__ <class '__main__.M_B'> B ()
>>>
>>>
>>> class C(A, B): pass
...
M_A.__prepare__ <class '__main__.M_A'> C (<class '__main__.A'>, <class '__main__.B'>)
M_A.__new__ <class '__main__.M_A'> C (<class '__main__.A'>, <class '__main__.B'>)
M_B.__new__ <class '__main__.M_B'> C (<class '__main__.A'>, <class '__main__.B'>) {'__module__': '__main__'}
M_A.__new__ <class '__main__.M_B'> C (<class '__main__.A'>, <class '__main__.B'>)
>>>
>>> 'M_B_was_here' in C.__dict__
False
>>>

__build_class__ calls M_A.__prepare__, so the new class won't have a 'M_B_was_here' attribute (though its __class__ is M_B).

>>> class C2(B, A): pass
...
M_B.__prepare__ <class '__main__.M_B'> C2 (<class '__main__.B'>, <class '__main__.A'>)
M_B.__new__ <class '__main__.M_B'> C2 (<class '__main__.B'>, <class '__main__.A'>) {'M_B_was_here': True, '__module__': '__main__'}
M_A.__new__ <class '__main__.M_B'> C2 (<class '__main__.B'>, <class '__main__.A'>)
>>>
>>> 'M_B_was_here' in C2.__dict__
True
>>>

I we reverse the order of the bases, M_B.__prepare__ is called.

>>> C.__class__
<class '__main__.M_B'>
>>> C2.__class__
<class '__main__.M_B'>

But the "real" metaclass of both classes is M_B.

(Sorry for the long post.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Sun Dec  5 13:21:57 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 05 Dec 2010 12:21:57 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1291551717.14.0.570808071122.issue10292@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Okay, this bug has been fixed in the 2.7 series. Python 2.6 is now in security-fix-only mode which means that there will not be a fix for it.

Therefore, I close this issue.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10292>
_______________________________________

From report at bugs.python.org  Sun Dec  5 13:28:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Dec 2010 12:28:26 +0000
Subject: [issue10629] Arbitrary precision
In-Reply-To: <1291538596.71.0.765304275074.issue10629@psf.upfronthosting.co.za>
Message-ID: <1291552106.55.0.0430925490268.issue10629@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Note that while Python's long type gives you unlimited-size integers, the float type doesn't make such promises: it is just a double-precision float.  As such, math.factorial(1234) cannot be interpreted; it would simply be positive infinity.

----------
components: +Interpreter Core -Regular Expressions
nosy: +georg.brandl, mark.dickinson
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10629>
_______________________________________

From report at bugs.python.org  Sun Dec  5 14:05:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Dec 2010 13:05:20 +0000
Subject: [issue10629] Arbitrary precision
In-Reply-To: <1291538596.71.0.765304275074.issue10629@psf.upfronthosting.co.za>
Message-ID: <1291554320.73.0.333310578776.issue10629@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Right; this is expected behaviour.  The error you're seeing comes from the implicit conversion of 1234! from long to float.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10629>
_______________________________________

From report at bugs.python.org  Sun Dec  5 15:09:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Dec 2010 14:09:46 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291558186.9.0.167442361479.issue10576@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Sun Dec  5 16:33:24 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 05 Dec 2010 15:33:24 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1291563204.09.0.907861574509.issue5587@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Based on David Stanek's patch I've made a patch against the current py3k branch. The only difference is, that dict_proxy.__repr__ instead of simply returning the repr of the dict, returns approximately "dict_proxy({!r})".format(self.dict).

----------
nosy: +durban
Added file: http://bugs.python.org/file19949/issue5587.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Sun Dec  5 16:40:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 05 Dec 2010 15:40:19 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1291563619.67.0.637775235686.issue5587@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the patch! Can you include also a test that verifies that the repr is printed correctly?
(You can take a look at #7310 if you want to see a possible approach.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Sun Dec  5 16:53:59 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 05 Dec 2010 15:53:59 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1291564439.24.0.457765692989.issue5587@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> Thanks for the patch! Can you include also a test that verifies
> that the repr is printed correctly?

Sure. Where should I put the test? I didn't found any dict_proxy tests, except in test_descr.py ("# Classes don't allow __dict__ assignment and have readonly dicts").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Sun Dec  5 17:10:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Dec 2010 16:10:34 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291565434.15.0.569401623558.issue10516@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19947/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sun Dec  5 17:10:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Dec 2010 16:10:40 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291565440.18.0.530613577696.issue10516@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19948/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sun Dec  5 17:19:06 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 05 Dec 2010 16:19:06 +0000
Subject: [issue10630] dict_proxy.keys() / values() / items() are lists
In-Reply-To: <1291565946.17.0.111097012254.issue10630@psf.upfronthosting.co.za>
Message-ID: <1291565946.17.0.111097012254.issue10630@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The keys, values and items methods of dict_proxy return a list, while dict.keys, etc. return dictionary views (dict_keys, etc.). dict_proxy is used as the __dict__ attribute of classes. This is documented at http://docs.python.org/dev/py3k/reference/datamodel.html under "Custom classes" as "Special attributes: ... __dict__ is the dictionary containing the class?s namespace ..." While __dict__ is not actually dict, it probably should behave like a dict as close as possible. For example set operations work for dict.keys(), but not for dict_proxy.keys().

----------
components: Interpreter Core
messages: 123427
nosy: durban
priority: normal
severity: normal
status: open
title: dict_proxy.keys() / values() / items() are lists
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10630>
_______________________________________

From report at bugs.python.org  Sun Dec  5 17:49:21 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 05 Dec 2010 16:49:21 +0000
Subject: [issue10631] ZipFile and current directory change
In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>
Message-ID: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Is this intended behavior? Creating zipfile.ZipFile with
relative path and changing current directory, relative path
is resolved from new directory not from the directory object
was created.

F:\>py3k
Python 3.2a4+ (py3k, Dec  3 2010, 22:11:05) [MSC v.1200 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
[67577 refs]
>>> zip = zipfile.ZipFile("non-ascii-cp932.zip", "r")
[68999 refs]
>>> import os
[69001 refs]
>>> os.mkdir("temp")
[69001 refs]
>>> os.chdir("temp")
[69001 refs]
>>> zip.extractall()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "e:\python-dev\py3k\lib\zipfile.py", line 992, in extractall
    self.extract(zipinfo, path, pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 980, in extract
    return self._extract_member(member, path, pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 1023, in _extract_member
    source = self.open(member, pwd=pwd)
  File "e:\python-dev\py3k\lib\zipfile.py", line 901, in open
    zef_file = io.open(self.filename, 'rb')
IOError: [Errno 2] No such file or directory: 'non-ascii-cp932.zip'
[69128 refs]

----------
messages: 123428
nosy: ocean-city
priority: normal
severity: normal
status: open
title: ZipFile and current directory change
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10631>
_______________________________________

From report at bugs.python.org  Sun Dec  5 18:57:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 17:57:25 +0000
Subject: [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1291571845.24.0.396462293879.issue9101@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> open
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9101>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:00:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 18:00:29 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1291572029.65.0.264961342194.issue6490@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will refresh the patch, update it to recommend use as a context manager, and submit the patch here for review before committing.  It?s too late for 2.6, though.

Benjamin, I hope you won?t mind me taking the assignment from you.

----------
assignee: benjamin.peterson -> eric.araujo
nosy: +eric.araujo
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:09:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Dec 2010 18:09:27 +0000
Subject: [issue10631] ZipFile and current directory change
In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>
Message-ID: <1291572567.08.0.893391613355.issue10631@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know, but I wouldn't call it a bug either.
In general it's not recommended to change the current directory except at the very beginning of your application.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10631>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:15:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Dec 2010 18:15:15 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291572915.92.0.290226116797.issue10516@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Objects/dictobject.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:16:04 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 05 Dec 2010 18:16:04 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291572964.25.0.924901797422.issue10626@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

I've attached a patch that removes the code that installs a handler to the futures logger.

I'm not sure if this is the correct approach though - it means that "impossible" errors will only be reported to the user through a message like "no handler installed for logger". Maybe it is OK because this logging really shouldn't happen.

Thoughts?

----------
keywords: +patch
Added file: http://bugs.python.org/file19950/logging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:21:26 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 05 Dec 2010 18:21:26 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291573286.32.0.473926102189.issue8194@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/issue8194>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:26:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 18:26:53 +0000
Subject: [issue10630] dict_proxy.keys() / values() / items() are lists
In-Reply-To: <1291565946.17.0.111097012254.issue10630@psf.upfronthosting.co.za>
Message-ID: <1291573613.53.0.478881217034.issue10630@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10630>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:27:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 18:27:27 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1291573647.98.0.623264435381.issue5587@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Sun Dec  5 19:53:51 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 05 Dec 2010 18:53:51 +0000
Subject: [issue10632] multiprocessing gene
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>


New submission from Brian Quinlan <brian at sweetapp.com>:

multiprocessing generates fatal error "Invalid thread state for this thread" in PyThreadState_Swap

This seems to happen on RHEL 5 and Centos 5.5

Here is the minimal repro:
>>> import multiprocessing.managers
>>> mpp = multiprocessing.Pool(4)
>>> sm = multiprocessing.managers.SyncManager()
>>> sm.start()

See http://bugs.python.org/issue10517 for more details

----------
assignee: jnoller
components: Library (Lib)
messages: 123433
nosy: bquinlan, jnoller
priority: high
severity: normal
status: open
title: multiprocessing gene
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10632>
_______________________________________

From report at bugs.python.org  Sun Dec  5 20:00:42 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 05 Dec 2010 19:00:42 +0000
Subject: [issue10517] test_concurrent_futures crashes with "Fatal Python
	error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1291575642.91.0.230003388961.issue10517@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

I've filed a new bug (http://bugs.python.org/issue10632) against multiprocessing and this bug dependent on it.

In the meantime, I can't repro this on ubuntu 10.04 LTS so I'm going to install Centos and give that a go.

----------
dependencies: +multiprocessing gene

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Sun Dec  5 20:04:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Dec 2010 19:04:44 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1291575884.94.0.398471521067.issue7475@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As per 

http://mail.python.org/pipermail/python-dev/2010-December/106374.html

I think this checkin should be reverted, as it's breaking the language moratorium.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sun Dec  5 20:12:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Dec 2010 19:12:16 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1291576336.85.0.725830037113.issue7475@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I leave this to MAL, on whose behalf I finished this to be in time for beta.

----------
assignee:  -> lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Sun Dec  5 20:17:38 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 05 Dec 2010 19:17:38 +0000
Subject: [issue10632] multiprocessing generates a fatal error
In-Reply-To: <1291575231.48.0.0739915325097.issue10632@psf.upfronthosting.co.za>
Message-ID: <1291576658.13.0.194820950788.issue10632@psf.upfronthosting.co.za>


Changes by Brian Quinlan <brian at sweetapp.com>:


----------
title: multiprocessing gene -> multiprocessing generates a fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10632>
_______________________________________

From report at bugs.python.org  Sun Dec  5 20:21:19 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Dec 2010 19:21:19 +0000
Subject: [issue10631] ZipFile and current directory change
In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>
Message-ID: <1291576879.4.0.960141480079.issue10631@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

More formally: it's unspecified. I'd like to propose this general principle: If you pass a relative path to some library that gets stored in the library, it's unspecified whether the cwd is consider at the point of passing the path or at the point of using it in some operation.

Applications that want to be cwd-agnostic must always use abspath.

The only exceptions are operations where there is some explicit open() operation that is documented to interpret the path name; for these, it is clear that the cwd is considered inside the open().

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10631>
_______________________________________

From report at bugs.python.org  Sun Dec  5 21:33:00 2010
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCl0LvRg9GC0YfQuNC9?=)
Date: Sun, 05 Dec 2010 20:33:00 +0000
Subject: [issue10596] modulo operator bug
In-Reply-To: <1291204399.82.0.975884133816.issue10596@psf.upfronthosting.co.za>
Message-ID: <1291581180.89.0.565985509052.issue10596@psf.upfronthosting.co.za>


?????? ??????? <sercxjo at gmail.com> added the comment:

Yes i agree,
the first example is the result of rounding error, as well as here:
>>> 4.0-2.22044604925e-16==4.0
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10596>
_______________________________________

From report at bugs.python.org  Mon Dec  6 00:14:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 23:14:55 +0000
Subject: [issue8910] Write a text file explaining why Lib/test/data exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1291590895.85.0.481941096399.issue8910@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Temporarily reopening so that Martin can decide whether he wants to add Lib/test/data/README to msi.py

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8910>
_______________________________________

From report at bugs.python.org  Mon Dec  6 00:32:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Dec 2010 23:32:48 +0000
Subject: [issue8910] Write a text file explaining why Lib/test/data exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1291591968.56.0.501018866419.issue8910@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

All README files are automatically packages, and so is this one.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8910>
_______________________________________

From report at bugs.python.org  Mon Dec  6 00:40:51 2010
From: report at bugs.python.org (Alex Leone)
Date: Sun, 05 Dec 2010 23:40:51 +0000
Subject: [issue10633] string.format() Unexpected output with numeric '#'
	prefix and 0 width
In-Reply-To: <1291592451.76.0.667940420778.issue10633@psf.upfronthosting.co.za>
Message-ID: <1291592451.76.0.667940420778.issue10633@psf.upfronthosting.co.za>


New submission from Alex Leone <acleone at gmail.com>:

When using the '#' to prefix a numeric argument in format() with a '0x' or others, the 0-width padding takes into account the '0x' characters.  This is unexpected - the 0-width should NOT take into account the prefix.

Current Behavior:
> "{0:#02x}".format(10)
'0xa'

Expected Output:
> "{0:#02x}".format(10)
'0x0a'

(note that the '0a' is two characters long, as it should be)

----------
components: Library (Lib)
messages: 123441
nosy: Alex.Leone
priority: normal
severity: normal
status: open
title: string.format() Unexpected output with numeric '#' prefix and 0 width
type: behavior
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/issue10633>
_______________________________________

From report at bugs.python.org  Mon Dec  6 00:57:24 2010
From: report at bugs.python.org (Eric Pruitt)
Date: Sun, 05 Dec 2010 23:57:24 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>


New submission from Eric Pruitt <eric.pruitt at gmail.com>:

If the current time zone changes on Windows, time.localtime will continue to return results that reflect the time zone the system used when the module was imported. My current work around is to use GetLocalTime from kernel32 with ctypes. Windows does not have a tzset() equivalent as it does in Linux, but it seems like modifying time.localtime to use GetLocalTime on Windows systems could make up for this shortcoming.

----------
components: Windows
messages: 123442
nosy: eric.pruitt
priority: normal
severity: normal
status: open
title: Windows timezone changes not reflected by time.localtime
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec  6 00:58:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 23:58:13 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1291593493.22.0.328718611832.issue10588@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon, eric.araujo, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10588>
_______________________________________

From report at bugs.python.org  Mon Dec  6 00:58:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 05 Dec 2010 23:58:33 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291593513.85.0.327795489465.issue10634@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib)
stage:  -> unit test needed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec  6 01:01:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 06 Dec 2010 00:01:11 +0000
Subject: [issue10633] string.format() Unexpected output with numeric '#'
	prefix and 0 width
In-Reply-To: <1291592451.76.0.667940420778.issue10633@psf.upfronthosting.co.za>
Message-ID: <1291593671.62.0.871412660032.issue10633@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I disagree that your expected output is how it should behave. I believe it's more likely that the user wants the entire field width specified. In addition, compatibility with %-formatting would dictate that we keep the current behavior.

 >>> '%#02x' % 10
'0xa'

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10633>
_______________________________________

From report at bugs.python.org  Mon Dec  6 01:05:25 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Mon, 06 Dec 2010 00:05:25 +0000
Subject: [issue10635] Calling subprocess.Popen with preexec_fn=signal.pause
	blocks forever
In-Reply-To: <1291593925.84.0.564814760891.issue10635@psf.upfronthosting.co.za>
Message-ID: <1291593925.84.0.564814760891.issue10635@psf.upfronthosting.co.za>


New submission from joseph.h.garvin <joseph.h.garvin at gmail.com>:

The following code will cause the interpreter to hang:

import subprocess
import signal
subprocess.Popen("/bin/echo", preexec_fn=signal.pause)

Replace "/bin/echo" with any valid program on your box, it's just the simplest Linux example. It's expected for signal.pause to block, but the documentation for Popen says that preexec_fn will be run in the /child/ process, so it shouldn't cause the interpreter running this code to block.

I'm going to guess Popen is using signals for some reason internally and signal.pause interferes with it. It's probably worth making sure that signals related functions work with preexec_fn in general.

----------
components: Library (Lib)
messages: 123444
nosy: joseph.h.garvin
priority: normal
severity: normal
status: open
title: Calling subprocess.Popen with preexec_fn=signal.pause blocks forever
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10635>
_______________________________________

From report at bugs.python.org  Mon Dec  6 01:19:56 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Mon, 06 Dec 2010 00:19:56 +0000
Subject: [issue10636] subprocess module has race condition with SIGCHLD
	handlers
In-Reply-To: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>
Message-ID: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>


New submission from joseph.h.garvin <joseph.h.garvin at gmail.com>:

The following code will result in a traceback 99% of the time, though it may take two runs (sometimes the first run won't trigger it, I think due to the changing in timing from genrating the .pyc file). It spawns an instance of /bin/echo, chosen because it's a very quick to finish program. Any program that executes faster than subprocess.Popen can return will work as a substitute though:

import signal
import subprocess

to_launch = None

def sig_chld_handler(signum, frame):
    global to_launch
    # Crashes here.
    # 'NoneType' object has no attribute 'poll'
    to_launch.poll()

    print to_launch.returncode

signal.signal(signal.SIGCHLD, sig_chld_handler)

to_launch = subprocess.Popen("/bin/echo")


And the traceback:


Traceback (most recent call last):
  File "/tmp/sigchld.py", line 15, in <module>
    to_launch = subprocess.Popen("/bin/echo")
  File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1130, in _execute_child
    data = _eintr_retry_call(os.read, errpipe_read, 1048576)
  File "/usr/lib/python2.6/subprocess.py", line 455, in _eintr_retry_call
    return func(*args)
  File "/tmp/sigchld.py", line 9, in sig_chld_handler
    to_launch.poll()
AttributeError: 'NoneType' object has no attribute 'poll'


I believe the problem is that the process completes before Popen can return, which means the assignment of to_launch hasn't happened yet, so it's not defined when we get into sig_chld_handler.

I tried to work around this issue by setting preexec_fn to signal.pause and sending the child process a signal after the assignment, but then ran into another bug: http://bugs.python.org/issue10635

If when it caught SIGCHLD python pushed an event onto its internal event loop to execute the handler, I think that would make sure it's deferred until after the assignment. There might be other consequences of that, but I'm not familiar with the interpreter internals. Alternatively it could be fixed with an API change -- let Popen return an object before it actually launches the process, and have a separate start() method.

----------
components: Library (Lib)
messages: 123445
nosy: joseph.h.garvin
priority: normal
severity: normal
status: open
title: subprocess module has race condition with SIGCHLD handlers
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10636>
_______________________________________

From report at bugs.python.org  Mon Dec  6 01:25:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 00:25:56 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291595156.27.0.592795346262.issue10634@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug in Python, but in the Microsoft CRT. Rewriting Python to not use the CRT anymore for this is non-trivial, in particular as the semantics of environment variables (TZ) needs to be considered.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec  6 01:33:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 00:33:56 +0000
Subject: [issue10636] subprocess module has race	condition with
	SIGCHLD	handlers
In-Reply-To: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>
Message-ID: <4CFC2F70.6070507@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If when it caught SIGCHLD python pushed an event onto its internal
> event loop to execute the handler, I think that would make sure it's
> deferred until after the assignment.

This is not a reasonable request. How long would you want to postpone
this? Suppose somebody writes

def foo():
    local_to_launch = subprocess.Popen("/bin/echo")
    return local_to_launch

local_to_launch = foo()

then deferring the signal until after the assignment would not help,
so the semantics of your proposed change are fuzzy.

> There might be other
> consequences of that, but I'm not familiar with the interpreter
> internals. Alternatively it could be fixed with an API change -- let
> Popen return an object before it actually launches the process, and
> have a separate start() method.

The right approach is to use sigblock/sigsetmask before creating the
process, and then again after creating it. Unfortunately, these aren't
exposed from the signal module.

----------
nosy: +loewis
title: subprocess module has race condition with SIGCHLD handlers -> subprocess module has race	condition with SIGCHLD	handlers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10636>
_______________________________________

From report at bugs.python.org  Mon Dec  6 02:16:12 2010
From: report at bugs.python.org (joseph.h.garvin)
Date: Mon, 06 Dec 2010 01:16:12 +0000
Subject: [issue10636] subprocess module has race	condition with
	SIGCHLD	handlers
In-Reply-To: <1291594796.46.0.99547851622.issue10636@psf.upfronthosting.co.za>
Message-ID: <1291598172.09.0.989568064772.issue10636@psf.upfronthosting.co.za>


joseph.h.garvin <joseph.h.garvin at gmail.com> added the comment:

Sorry I wasn't trying to make a request, just suggesting one potential 'fix' (I agree that it isn't really though) to make things more intutive.

Unless the app is delayed from launching until after the assignment finishes though I think a workaround is required. When it's deferred until after the assignment you at least have the ability to get it stored into a global. When it's not deferred I think you're required to something like disable SIGCHLD like you say, spawn the child, enable, and then manually poll each of the subprocess popen objects you've opened before to see if they died while the signal was down.

I realize now this isn't really a bug. Principle of least surprise is probably too much to hope for with signals anyway. Feel free to close unless you want to leave it open as a bug to get sigblock/sigsetmask in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10636>
_______________________________________

From report at bugs.python.org  Mon Dec  6 04:17:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 03:17:16 +0000
Subject: [issue10633] string.format() Unexpected output with numeric '#'
	prefix and 0 width
In-Reply-To: <1291592451.76.0.667940420778.issue10633@psf.upfronthosting.co.za>
Message-ID: <1291605436.55.0.192751625776.issue10633@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Eric, I'm assuming you just forgot to close this.  On the other hand, if you wanted a +1 from another dev, you've got it :)  Besides the considerations you mentioned, changing this would be a significant backward incompatibility, and is therefore pretty much ruled out at this point, no matter what anyone might want.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10633>
_______________________________________

From report at bugs.python.org  Mon Dec  6 04:55:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 03:55:15 +0000
Subject: [issue10631] ZipFile and current directory change
In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>
Message-ID: <1291607715.03.0.0685583162794.issue10631@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So, Martin, are you then arguing that this should in fact be considered a bug in ZipFile?  The documentation for the constructor says "Open a ZIP file, where file can be either a path to a file (a string) or a file-like object."  Reading that I would certainly expect it to accept a relative path, and for that path to be relative to the CWD at the time I called ZipFile, not at the time I called extractall.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10631>
_______________________________________

From report at bugs.python.org  Mon Dec  6 05:05:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 06 Dec 2010 04:05:36 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291608336.11.0.859331343079.issue10626@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For 3.2, writing such errors directly to stderr would be fine (we already do that in other places via PyErr_WriteUnraisable)

The test could then be modified to use test.support.captured_output to temporarily replace stderr and look at the output.

The problem of avoiding interfering with application level handlers while having unraisable errors visible by default is probably the biggest reason past attempts to get the standard library using the logging module internally haven't gained much traction :P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Mon Dec  6 05:08:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 06 Dec 2010 04:08:58 +0000
Subject: [issue10637] Calling CloseHandle twice (Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Very sorry, I created the bug calling CloseHandle twice
in Modules/posixmodule.c. I think this should be fixed
before beta1 released. Can I commit it?

----------
components: None
files: posixmodule.diff
keywords: needs review, patch
messages: 123452
nosy: georg.brandl, ocean-city
priority: release blocker
severity: normal
stage: commit review
status: open
title: Calling CloseHandle twice (Modules/posixmodule.c)
versions: Python 3.2
Added file: http://bugs.python.org/file19951/posixmodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 05:30:21 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 06 Dec 2010 04:30:21 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291609821.56.0.67586942078.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Bo?tjan,

"a shallow copy": I took this directly from the documentation of dicts, which says:

   "D.copy() -> a shallow copy of D")

As I mentioned in an earlier message, the doc-strings of list and dict methods are inconsistent in more than one way, so I'm going to leave this decision to the committer. I'll be happy to help with fixes too.

Re your other question, in the Python source root, dictionaries are mostly implemented in Objects/dictobject.c - there's an array called mapp_methods that lists the functions used to implement relevant methods. For copy() it lists:

    {"copy",            (PyCFunction)dict_copy,         METH_NOARGS,

So you need dict_copy. Note that it's just a wrapper (of another wrapper, by the way) bit it's a good place to start. Arm yourself with an editor or IDE with some code-searching capabilities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 05:41:25 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 06 Dec 2010 04:41:25 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1291610485.92.0.900925714519.issue10482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The general idea is sound. My work colleagues have certainly had to implement their own reader/writer thread equivalents to keep subprocess from blocking.

It makes sense to provide more robust public support for such techniques in process itself.

----------
nosy: +ncoghlan
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:18:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 07:18:24 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <4CFC8E3C.8080007@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Very sorry, I created the bug calling CloseHandle twice
> in Modules/posixmodule.c. I think this should be fixed
> before beta1 released. Can I commit it?

Even if you commit it now, it won't get into beta1: the
Windows binaries for that are already built.

----------
nosy: +loewis
title: Calling CloseHandle twice (Modules/posixmodule.c) -> Calling CloseHandle twice	(Modules/posixmodule.c)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:29:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Dec 2010 07:29:28 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291620568.32.0.0464436832709.issue10637@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What is the result of calling it twice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:34:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 07:34:23 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291620863.93.0.92631883551.issue10637@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The second CloseHandle call will fail. As we are not checking the CloseHandle result, this has no further consequences, AFAICT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:35:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 07:35:43 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291620943.45.0.830880141558.issue10637@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

quick followup: there is a chance that this closes the wrong file due to race conditions, in case a different thread opens a file in-between that gets the same handle. Due to the GIL, this is unlikely

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:37:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Dec 2010 07:37:52 +0000
Subject: [issue10635] Calling subprocess.Popen with preexec_fn=signal.pause
	blocks forever
In-Reply-To: <1291593925.84.0.564814760891.issue10635@psf.upfronthosting.co.za>
Message-ID: <1291621072.7.0.109366946367.issue10635@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

After forking, the parent waits for the child's exec call to determine if it succeeds.  Otherwise, you wouldn't get an exception in the parent when you do

Popen('/bin/ech')

or somesuch.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10635>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:40:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Dec 2010 07:40:36 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291621236.04.0.489948569298.issue10637@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I would say this is an acceptable bug in a beta release.  Will fix it after the release is done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:42:43 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 06 Dec 2010 07:42:43 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291621363.82.0.380534726596.issue10637@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, I'm not sure. I didn't realize it while running python_d.exe.
I just realized it while re-reading source code.

MSDN says, (http://msdn.microsoft.com/en-us/library/ms724211%28VS.85%29.aspx)

> If the application is running under a debugger, the function will
> throw an exception if it receives either a handle value that is not
> valid or a pseudo-handle value. This can happen if you close a handle
> twice, (snip)

So if someone run python_d.exe in debugger, maybe he/she can see
exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 08:43:33 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 06 Dec 2010 07:43:33 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291621413.35.0.278974229605.issue10637@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg123461

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Mon Dec  6 12:49:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 06 Dec 2010 11:49:45 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1291575884.94.0.398471521067.issue7475@psf.upfronthosting.co.za>
Message-ID: <4CFCCDD0.5080409@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:
> 
> As per 
> 
> http://mail.python.org/pipermail/python-dev/2010-December/106374.html
> 
> I think this checkin should be reverted, as it's breaking the language moratorium.

I've asked Guido. We may have to revert the addition of the new
methods and then readd them for 3.3, but I don't really see
them as difficult to implement for the other Python implementations,
since they are just interfaces to the codec sub-system.

The readdition of the codecs and changes to support them in the
codec system do not fall under the moratorium, since they are
stdlib changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Mon Dec  6 13:23:01 2010
From: report at bugs.python.org (Johann Hanne)
Date: Mon, 06 Dec 2010 12:23:01 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291638181.11.0.913122380612.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

> Traditionally, MingW-compiled Python binaries would often be
binary-incompatible

I don't plan to distribute a MinGW compiled package as an alternative to the official MSVC based build. In my particular use case, I compile everything into a single exe and put the Lib/*.py files into a single zip file. The result is a two-file Python distribution which doesn't need an installation. If somebody is interested, I can elaborate, but this would be off-topic here.

As for the reproducibility issue: The configure/Makefile system coming with Python simply doesn't support creating a Windows build. I hope it's clear that the patch is NOT about creating a Windows installer. If this is a requirement for getting my patch in, please let me know so I can stop wasting my time!

Whatsoever, if you simply want to reproduce that my compile (!) fixes work, please follow these steps:
- Start a MinGW shell and cd into the Python source tree
- CFLAGS="-IPC -IPython" ./configure
- Remove the created pyconfig.h and replace PC/pyconfig.h with the manually modified version I'm attaching
- Modify the Makefile:
-- Remove pwdmodule.c from the MODOBJS variable
-- Add to the MODOBJS variable: PC/dl_nt.o PC/import_nt.o
-- Remove the LIBOBJS variable assigment
-- Edit the "# Build the interpreter" paragraph: Add PC/empty.o to the rule dependencies *AND* after "...$(SYSLIBS) $(LDLAST)"
- Modify PC/empty.c: Add "#include "Python.h" as first line; replace 'return 0;' by 'wchar_t *wargv[] = { L"python.exe", NULL }; return Py_Main(1, wargv);'
- Run make
- Add the the full path to the Lib directory to your PYTHONPATH

----------
Added file: http://bugs.python.org/file19952/pyconfig.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Mon Dec  6 13:32:46 2010
From: report at bugs.python.org (Johann Hanne)
Date: Mon, 06 Dec 2010 12:32:46 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291638766.76.0.34436705431.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

As promised, here comes the list of modules which successfully compile with MinGW:


./Python-3.1.3/PC/import_nt.o
./Python-3.1.3/PC/_subprocess.o
./Python-3.1.3/PC/dl_nt.o
./Python-3.1.3/PC/msvcrtmodule.o
./Python-3.1.3/PC/winreg.o
./Python-3.1.3/Parser/pgen.o
./Python-3.1.3/Parser/grammar1.o
./Python-3.1.3/Parser/parser.o
./Python-3.1.3/Parser/listnode.o
./Python-3.1.3/Parser/parsetok.o
./Python-3.1.3/Parser/tokenizer.o
./Python-3.1.3/Parser/printgrammar.o
./Python-3.1.3/Parser/myreadline.o
./Python-3.1.3/Parser/firstsets.o
./Python-3.1.3/Parser/metagrammar.o
./Python-3.1.3/Parser/grammar.o
./Python-3.1.3/Parser/acceler.o
./Python-3.1.3/Parser/node.o
./Python-3.1.3/Parser/bitset.o
./Python-3.1.3/Python/getcompiler.o
./Python-3.1.3/Python/codecs.o
./Python-3.1.3/Python/pystrtod.o
./Python-3.1.3/Python/pyfpe.o
./Python-3.1.3/Python/getargs.o
./Python-3.1.3/Python/modsupport.o
./Python-3.1.3/Python/getopt.o
./Python-3.1.3/Python/formatter_unicode.o
./Python-3.1.3/Python/mysnprintf.o
./Python-3.1.3/Python/pyctype.o
./Python-3.1.3/Python/sysmodule.o
./Python-3.1.3/Python/errors.o
./Python-3.1.3/Python/pymath.o
./Python-3.1.3/Python/pythonrun.o
./Python-3.1.3/Python/pystrcmp.o
./Python-3.1.3/Python/pystate.o
./Python-3.1.3/Python/getversion.o
./Python-3.1.3/Python/_warnings.o
./Python-3.1.3/Python/Python-ast.o
./Python-3.1.3/Python/frozen.o
./Python-3.1.3/Python/getcopyright.o
./Python-3.1.3/Python/asdl.o
./Python-3.1.3/Python/pyarena.o
./Python-3.1.3/Python/importdl.o
./Python-3.1.3/Python/compile.o
./Python-3.1.3/Python/dtoa.o
./Python-3.1.3/Python/getplatform.o
./Python-3.1.3/Python/traceback.o
./Python-3.1.3/Python/ceval.o
./Python-3.1.3/Python/mystrtoul.o
./Python-3.1.3/Python/thread.o
./Python-3.1.3/Python/symtable.o
./Python-3.1.3/Python/structmember.o
./Python-3.1.3/Python/future.o
./Python-3.1.3/Python/graminit.o
./Python-3.1.3/Python/peephole.o
./Python-3.1.3/Python/marshal.o
./Python-3.1.3/Python/import.o
./Python-3.1.3/Python/bltinmodule.o
./Python-3.1.3/Python/dynload_win.o
./Python-3.1.3/Python/ast.o
./Python-3.1.3/Modules/sha512module.o
./Python-3.1.3/Modules/socketmodule.o
./Python-3.1.3/Modules/expat/xmltok.o
./Python-3.1.3/Modules/expat/xmlrole.o
./Python-3.1.3/Modules/expat/xmlparse.o
./Python-3.1.3/Modules/_csv.o
./Python-3.1.3/Modules/_randommodule.o
./Python-3.1.3/Modules/errnomodule.o
./Python-3.1.3/Modules/_weakref.o
./Python-3.1.3/Modules/arraymodule.o
./Python-3.1.3/Modules/symtablemodule.o
./Python-3.1.3/Modules/zipimport.o
./Python-3.1.3/Modules/sha256module.o
./Python-3.1.3/Modules/mmapmodule.o
./Python-3.1.3/Modules/_ctypes/_ctypes_test.o
./Python-3.1.3/Modules/_ctypes/libffi/src/prep_cif.o
./Python-3.1.3/Modules/_ctypes/libffi/src/x86/ffi.o
./Python-3.1.3/Modules/_ctypes/libffi/src/x86/win32.o
./Python-3.1.3/Modules/_ctypes/callbacks.o
./Python-3.1.3/Modules/_ctypes/stgdict.o
./Python-3.1.3/Modules/_ctypes/_ctypes.o
./Python-3.1.3/Modules/_ctypes/callproc.o
./Python-3.1.3/Modules/_ctypes/malloc_closure.o
./Python-3.1.3/Modules/_ctypes/cfield.o
./Python-3.1.3/Modules/operator.o
./Python-3.1.3/Modules/posixmodule.o
./Python-3.1.3/Modules/md5module.o
./Python-3.1.3/Modules/timemodule.o
./Python-3.1.3/Modules/_functoolsmodule.o
./Python-3.1.3/Modules/datetimemodule.o
./Python-3.1.3/Modules/cmathmodule.o
./Python-3.1.3/Modules/zlibmodule.o
./Python-3.1.3/Modules/_threadmodule.o
./Python-3.1.3/Modules/itertoolsmodule.o
./Python-3.1.3/Modules/_lsprof.o
./Python-3.1.3/Modules/_tkinter.o
./Python-3.1.3/Modules/getbuildinfo.o
./Python-3.1.3/Modules/_collectionsmodule.o
./Python-3.1.3/Modules/_localemodule.o
./Python-3.1.3/Modules/_io/iobase.o
./Python-3.1.3/Modules/_io/bytesio.o
./Python-3.1.3/Modules/_io/stringio.o
./Python-3.1.3/Modules/_io/_iomodule.o
./Python-3.1.3/Modules/_io/textio.o
./Python-3.1.3/Modules/_io/bufferedio.o
./Python-3.1.3/Modules/_io/fileio.o
./Python-3.1.3/Modules/_struct.o
./Python-3.1.3/Modules/_codecsmodule.o
./Python-3.1.3/Modules/selectmodule.o
./Python-3.1.3/Modules/rotatingtree.o
./Python-3.1.3/Modules/sha1module.o
./Python-3.1.3/Modules/unicodedata.o
./Python-3.1.3/Modules/parsermodule.o
./Python-3.1.3/Modules/xxsubtype.o
./Python-3.1.3/Modules/_heapqmodule.o
./Python-3.1.3/Modules/audioop.o
./Python-3.1.3/Modules/_multiprocessing/win32_functions.o
./Python-3.1.3/Modules/_multiprocessing/semaphore.o
./Python-3.1.3/Modules/_multiprocessing/pipe_connection.o
./Python-3.1.3/Modules/_multiprocessing/multiprocessing.o
./Python-3.1.3/Modules/_multiprocessing/socket_connection.o
./Python-3.1.3/Modules/_bisectmodule.o
./Python-3.1.3/Modules/gcmodule.o
./Python-3.1.3/Modules/_sre.o
./Python-3.1.3/Modules/_json.o
./Python-3.1.3/Modules/mathmodule.o
./Python-3.1.3/Modules/signalmodule.o
./Python-3.1.3/Modules/pyexpat.o
./Python-3.1.3/Modules/binascii.o
./Python-3.1.3/Modules/_pickle.o
./Python-3.1.3/Objects/unicodeobject.o
./Python-3.1.3/Objects/enumobject.o
./Python-3.1.3/Objects/codeobject.o
./Python-3.1.3/Objects/methodobject.o
./Python-3.1.3/Objects/moduleobject.o
./Python-3.1.3/Objects/cobject.o
./Python-3.1.3/Objects/exceptions.o
./Python-3.1.3/Objects/floatobject.o
./Python-3.1.3/Objects/unicodectype.o
./Python-3.1.3/Objects/bytesobject.o
./Python-3.1.3/Objects/weakrefobject.o
./Python-3.1.3/Objects/fileobject.o
./Python-3.1.3/Objects/structseq.o
./Python-3.1.3/Objects/memoryobject.o
./Python-3.1.3/Objects/dictobject.o
./Python-3.1.3/Objects/classobject.o
./Python-3.1.3/Objects/setobject.o
./Python-3.1.3/Objects/object.o
./Python-3.1.3/Objects/obmalloc.o
./Python-3.1.3/Objects/cellobject.o
./Python-3.1.3/Objects/descrobject.o
./Python-3.1.3/Objects/tupleobject.o
./Python-3.1.3/Objects/typeobject.o
./Python-3.1.3/Objects/genobject.o
./Python-3.1.3/Objects/iterobject.o
./Python-3.1.3/Objects/listobject.o
./Python-3.1.3/Objects/bytearrayobject.o
./Python-3.1.3/Objects/frameobject.o
./Python-3.1.3/Objects/boolobject.o
./Python-3.1.3/Objects/longobject.o
./Python-3.1.3/Objects/funcobject.o
./Python-3.1.3/Objects/complexobject.o
./Python-3.1.3/Objects/rangeobject.o
./Python-3.1.3/Objects/capsule.o
./Python-3.1.3/Objects/bytes_methods.o
./Python-3.1.3/Objects/abstract.o
./Python-3.1.3/Objects/sliceobject.o

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Mon Dec  6 14:28:37 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Mon, 06 Dec 2010 13:28:37 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291642117.17.0.980388110448.issue8194@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Can we get a decision on this? It's kind of sad that this regression wasn't fixed in 2.7.1.

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Mon Dec  6 14:43:19 2010
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 06 Dec 2010 13:43:19 +0000
Subject: [issue10638] PyArg_ParseTuple: refcount in nested tuples
In-Reply-To: <1291642999.53.0.225447944395.issue10638@psf.upfronthosting.co.za>
Message-ID: <1291642999.53.0.225447944395.issue10638@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

There is an issue in PyArg_ParseTuple() when using nested tuple arguments: it accepts a pure Python tuple-like argument, but it cannot work properly because PyArg_ParseTuple() is supposed to return borrowed references to the objects.  For example, here is an attack on functools.partial().__setstate__(), which is written using

    PyArg_ParseTuple(args, "(OOOO)", ...)

Running crasher.py crashes a debug build of Python, for me with Fatal Python error: _functoolsmodule.c:158 object at 0x9011748 has negative ref count -606348322.

The only way I can see to fix the crasher is to restrict the kind of argument that can be passed to mean a nested tuple.  To be paranoid, it should only allow real tuples; a bit more flexibly, lists probably work ok too.

----------
components: Interpreter Core
files: crasher.py
messages: 123466
nosy: arigo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple: refcount in nested tuples
Added file: http://bugs.python.org/file19953/crasher.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10638>
_______________________________________

From report at bugs.python.org  Mon Dec  6 15:04:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Dec 2010 14:04:18 +0000
Subject: [issue10638] PyArg_ParseTuple: refcount in nested tuples
In-Reply-To: <1291642999.53.0.225447944395.issue10638@psf.upfronthosting.co.za>
Message-ID: <1291644258.75.0.907708486742.issue10638@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Duplicate of #6083?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10638>
_______________________________________

From report at bugs.python.org  Mon Dec  6 15:14:41 2010
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 06 Dec 2010 14:14:41 +0000
Subject: [issue10638] PyArg_ParseTuple: refcount in nested tuples
In-Reply-To: <1291642999.53.0.225447944395.issue10638@psf.upfronthosting.co.za>
Message-ID: <1291644881.03.0.485767359952.issue10638@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Indeed.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10638>
_______________________________________

From report at bugs.python.org  Mon Dec  6 15:49:55 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 06 Dec 2010 14:49:55 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1291609821.56.0.67586942078.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=8vYAg9SBGRciV8Za0K0ZGtrt+-APp4NJJiHoZ@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

mapp_methods ?   Don't you mean map_methods ?

----------
Added file: http://bugs.python.org/file19954/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">mapp_methods??? ?? Don&#39;t you mean??</span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">map_methods???</span>

From report at bugs.python.org  Mon Dec  6 15:55:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Dec 2010 14:55:24 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291647324.23.0.764792328261.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, he means mapp_methods.  Why don't you simply look at the file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 16:27:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 15:27:04 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291649224.39.0.865066278505.issue8194@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Even if the change may be straightforward, it requires a test.

----------
stage:  -> unit test needed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Mon Dec  6 16:43:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 06 Dec 2010 15:43:20 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291650200.27.0.703819801845.issue10634@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/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec  6 16:55:38 2010
From: report at bugs.python.org (Eric Pruitt)
Date: Mon, 06 Dec 2010 15:55:38 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291650938.58.0.551135626772.issue10634@psf.upfronthosting.co.za>


Eric Pruitt <eric.pruitt at gmail.com> added the comment:

Is there a way to force the time module to be reinitialized? I had no success experimenting with reload and del, but I assume that has something to do with the module being CRT based.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec  6 16:58:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 15:58:36 +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: <1291651116.11.0.00646780339343.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What is the status of this issue?  A grep for _PyUnicode_AsString quickly revealed a crash:

>>> from xml.etree.cElementTree import *
>>> e = Element('a')
>>> getattr(e, '\uD800')
Segmentation fault

I don't think this is the only one.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:10:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 16:10:00 +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: <1291651800.95.0.907451875772.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Another crash:

>>> from datetime import *
>>> datetime.now(timezone(timedelta(0), '\uD800')).strftime('%Z')
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:11:21 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 06 Dec 2010 16:11:21 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291651881.99.0.161147327497.issue10615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the explanations! These instructions should be turned into a patch.
Some questions already:
- Why is the generated pyconfig.h not good enough? Could we modify the ./configure script instead?
- the "empty.c" should remain empty... Why not use PC/WinMain.c instead?
- why is a WinMain required when python.c is supposed to define a main()?
Is the final binary a console application or a Windows application?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:36:53 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Dec 2010 16:36:53 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

When reindent.py runs, it will convert the line endings for each file it converts to the default line ending for the platform on which reindent.py runs. It would be better if reindent.py would retain line endings of the source file. Attached is a patch that addresses this issue.

----------
components: Demos and Tools
files: reindent-autonewline.patch
keywords: patch
messages: 123476
nosy: jaraco
priority: normal
severity: normal
status: open
title: reindent.py converts newlines to platform default
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19955/reindent-autonewline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:40:38 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Dec 2010 16:40:38 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1291653638.06.0.276256800539.issue10639@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file19955/reindent-autonewline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:42:44 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Dec 2010 16:42:44 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1291653764.59.0.582151142022.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Merged the patch with the latest trunk.

----------
Added file: http://bugs.python.org/file19956/reindent-autonewline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:51:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 16:51:04 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1291654264.46.0.832804569991.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.

----------
nosy: +eric.araujo
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Dec  6 17:52:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 16:52: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: <1291654350.01.0.246385970547.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

One of the uses of problematic uses of PyUnicode_GetSize() is in Macintosh Gestalt interface:



/* Convert a 4-char string object argument to an OSType value */
static int
convert_to_OSType(PyObject *v, OSType *pr)
{
    uint32_t tmp;
    if (!PyUnicode_Check(v) || PyUnicode_GetSize(v) != 4) {
    PyErr_SetString(PyExc_TypeError,
                    "OSType arg must be string of 4 chars");
    return 0;
    }
    memcpy((char *)&tmp, _PyUnicode_AsString(v), 4);
    *pr = (OSType)ntohl(tmp);
    return 1;
}

(Modules/_gestalt.c:41)

This function seems to require a bytes, not str argument as interpreting 4 UTF-8 bytes as an int makes little sense.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Dec  6 18:26:51 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 06 Dec 2010 17:26:51 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1291647324.23.0.764792328261.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTikSe1aHYdEZ-Hj2MW=p8MyM75XO8hVEEuWkADxe@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

mapp_methods looks like a typo. you know -- mapp_...? isn't map_... correct?

----------
Added file: http://bugs.python.org/file19957/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
mapp_methods looks like a typo. you know -- mapp_...? isn&#39;t map_... correct?

From report at bugs.python.org  Mon Dec  6 18:28:46 2010
From: report at bugs.python.org (holger krekel)
Date: Mon, 06 Dec 2010 17:28:46 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291656526.66.0.0190717863823.issue10548@psf.upfronthosting.co.za>


Changes by holger krekel <holger.krekel at gmail.com>:


----------
nosy: +hpk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Mon Dec  6 18:29:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 06 Dec 2010 17:29:02 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291656542.84.0.492442779776.issue10516@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

No, and please do not clutter this issue with any perceived typo discussions.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 18:38:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 17:38:05 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291657085.44.0.10513440754.issue10516@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19954/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 18:38:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 17:38:09 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291657089.11.0.479591006185.issue10516@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19957/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:16:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 18:16: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: <1291659362.73.0.867203438619.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that fixes several instances of unchecked _PyUnicode_AsString() result.  Not all fixes are completely trivial, so I would appreciate a review.

I did not attempt to fix Modules/_gestalt.c because I would like to hear from Ronald first.  (See my previous comment.)

The patch doe not have the unit tests yet, but I reported some test cases above and these should be easy to convert to unit tests.

----------
assignee: ronaldoussoren -> belopolsky
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19958/issue6697.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:25:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 18:25:16 +0000
Subject: [issue3446] center,
	ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1291659916.88.0.183579748428.issue3446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As a feature request for 2.x, I think this should be rejected.

Any objections?

The "behavior" part seem to have been fixed.

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> rejected
status: open -> pending
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3446>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:28:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 18:28:52 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1291660132.04.0.784805893748.issue2857@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> TCL only uses the codec for internal represenation. You might want to
> interface to TCL at the C level and use the codec there, but is that
> really a good reason to include the codec in the Python stdlib ?

I wonder if tkinter should use this encoding.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:29:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 18:29:33 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291660173.8.0.0944719813721.issue10548@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would expect this code to report an error of some sort, not pass as an expected failure.  The expected failure should be in the test case *only*, not in the setup or teardown methods.  That is, I don't think this is a bug, I think it is a feature that allows one to debug one's test infrastructure.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:39:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 18:39:42 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291660782.8.0.318401718888.issue8194@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kristjan, can you take a look?

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:41:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 18:41:41 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1291660901.22.0.314984640359.issue10634@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What needs reinitialization is not the time module, but the CRT. This is not possible without starting a completely new process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:42:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 06 Dec 2010 18:42:17 +0000
Subject: [issue4610] Unicode case mappings are incorrect
In-Reply-To: <1228834230.47.0.479389214751.issue4610@psf.upfronthosting.co.za>
Message-ID: <1291660937.48.0.456147276251.issue4610@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>> .swapcase() is just ...err... dumb^h^h^h^h questionably useful. 

> I agree with the rest of you that Python would be better-off
> without swapcase().

As long as str.upper/lower are based only on UnicodeData.txt 1-to-1 mappings, existence of str.swapcase() indicates to the users that they should not expect many-to-1 mappings.  Also it does seem to be occasionally used for testing.  -0 on removing it.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4610>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:47:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 06 Dec 2010 18:47:01 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291638181.11.0.913122380612.issue10615@psf.upfronthosting.co.za>
Message-ID: <4CFD2FA3.80500@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> As for the reproducibility issue: The configure/Makefile system
> coming with Python simply doesn't support creating a Windows build. I
> hope it's clear that the patch is NOT about creating a Windows
> installer. If this is a requirement for getting my patch in, please
> let me know so I can stop wasting my time!

That's why I was asking what the patch achieves - it was not clear
at all what the objective is. Not supporting the build of an installer
is fine (although that probably wouldn't be difficult). However, if
the patch doesn't manage to make "configure;make" work, it's IMO
useless. Having "make install" work in some form would be desirable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:47:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 06 Dec 2010 18:47:32 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1291661252.88.0.294799750367.issue9333@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'll come up with a patch to make the attribute always available, but raise OSError when the privilege is not held.

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Mon Dec  6 19:57:35 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 06 Dec 2010 18:57:35 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1291657089.16.0.0266208712732.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=BK=oEi=RYARTGJw_Br+s6onVSA5pqk_-qdctz@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Why mapp_methods, why not map_methods? Any reason for this?

----------
Added file: http://bugs.python.org/file19959/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
Why mapp_methods, why not map_methods? Any reason for this?

From report at bugs.python.org  Mon Dec  6 20:01:51 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 06 Dec 2010 19:01:51 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291662111.02.0.2050477515.issue10516@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19959/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:03:12 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 06 Dec 2010 19:03:12 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291662192.7.0.720942905936.issue10453@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

r86611 has introduced a regression:

$ mkdir dir1 dir2
$ python3.1 -m compileall dir1 dir2
Listing dir1 ...
Listing dir2 ...
$ python3.2 -m compileall dir1 dir2
usage: compileall.py [-h] [-l] [-f] [-q] [-b] [-d DESTDIR] [-x REGEXP]
                     [-i FILE]
                     [FILE|DIR]
compileall.py: error: unrecognized arguments: dir2

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:06:15 2010
From: report at bugs.python.org (holger krekel)
Date: Mon, 06 Dec 2010 19:06:15 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291662375.96.0.872764569012.issue10548@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

FWIW i tend to agree and would probably prefer setup/teardown to result in an error rather than be subsumed in an expected-to-fail marked test.  I guess if one regards setup/teardown as a place to implement pre/post-conditions than the changes suggested by Michael make more sense.  I'd like to see a more "real" use case / user than the abstract case provided here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:10:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 19:10:33 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291662633.32.0.687264498467.issue10516@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1) Obviously because they?re mapping methods, not map methods.

2) Again, opening up the file and looking through it for some seconds or minutes would have allowed you to understand it.

3) Again, this is not the right place to discuss this.

4) Again, please do not send HTML email to this tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:13:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 19:13:32 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291662812.56.0.290640896132.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Whoops, a nargs='?' should have been '*'.  Who wants to write the test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:15:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 19:15:47 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291662947.55.0.0263553107843.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm working on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:19:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Dec 2010 19:19:33 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291663173.76.0.244128077119.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me be more helpful, just in case.  This is the offending line:
parser.add_argument('compile_dest', metavar='FILE|DIR', nargs='?')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:21:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 19:21:10 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291663270.45.0.827780916568.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's the test.  The fix isn't as simple as making it nargs='*', though.

----------
Added file: http://bugs.python.org/file19960/compileall_multidir_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:33:09 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 06 Dec 2010 19:33:09 +0000
Subject: [issue10640] SystemError on pickling bytes >= 4GB
In-Reply-To: <1291663989.87.0.429691501814.issue10640@psf.upfronthosting.co.za>
Message-ID: <1291663989.87.0.429691501814.issue10640@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hagen at zhuliguan.net>:

Pickling a bytes object of length >= 2**32 results in a "SystemError: error return without exception set".

If pickling large bytes objects isn't supported, this should be documented and a helpful exception be raised.

----------
components: Library (Lib)
messages: 123499
nosy: hagen
priority: normal
severity: normal
status: open
title: SystemError on pickling bytes >= 4GB
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10640>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:45:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 19:45:59 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291664759.79.0.321366074331.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a fix.  This is not finished, though, because I see that I did not do an adequate review of the original patch.  There are still bugs in the -d and -i handling that need both tests and fixes.

----------
Added file: http://bugs.python.org/file19961/compileall_multidir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:52:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 19:52:58 +0000
Subject: [issue10640] SystemError on pickling bytes >= 4GB
In-Reply-To: <1291663989.87.0.429691501814.issue10640@psf.upfronthosting.co.za>
Message-ID: <1291665178.05.0.55147808869.issue10640@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I suspect this is a duplicate of issue 9614, or rather a subset of that issue.

----------
nosy: +alexandre.vassalotti, amaury.forgeotdarc, janglin, pitrou, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10640>
_______________________________________

From report at bugs.python.org  Mon Dec  6 20:49:56 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 06 Dec 2010 19:49:56 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1276459333.34.0.2819129099.issue6560@psf.upfronthosting.co.za>
Message-ID: <20101206194913.GA7420@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

Updated the patch to use the new BEGIN/END_SELECT_LOOP macros.

Also fixed a bug I spotted while doing this whereby when a
timeout was set, errors in select() or poll() would be
misreported as timeouts.

Will also upload at http://codereview.appspot.com/1487041/show

----------
Added file: http://bugs.python.org/file19962/baikie-hwundram-v5.diff
Added file: http://bugs.python.org/file19963/v5-replace-existing-classes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________
-------------- next part --------------
Add sendmsg(), recvmsg() and recvmsg_into() methods to sockets.

Based on a patch by Heiko Wundram.

Index: Doc/library/socket.rst
===================================================================
--- Doc/library/socket.rst	(revision 87092)
+++ Doc/library/socket.rst	(working copy)
@@ -177,6 +177,7 @@
           SOMAXCONN
           MSG_*
           SOL_*
+          SCM_*
           IPPROTO_*
           IPPORT_*
           INADDR_*
@@ -490,6 +491,43 @@
    Availability: Unix (maybe not all platforms).
 
 
+.. function:: CMSG_LEN(length)
+
+   Return the total length, without trailing padding, of an ancillary
+   data item with associated data of the given *length*.  This value
+   can often be used as the buffer size for :meth:`~socket.recvmsg` to
+   receive a single item of ancillary data, but :rfc:`3542` requires
+   portable applications to use :func:`CMSG_SPACE` and thus include
+   space for padding, even when the item will be the last in the
+   buffer.  Raises :exc:`OverflowError` if *length* is outside the
+   permissible range of values.
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
+.. function:: CMSG_SPACE(length)
+
+   Return the buffer size needed for :meth:`~socket.recvmsg` to
+   receive an ancillary data item with associated data of the given
+   *length*, along with any trailing padding.  The buffer space needed
+   to receive multiple items is the sum of the :func:`CMSG_SPACE`
+   values for their associated data lengths.  Raises
+   :exc:`OverflowError` if *length* is outside the permissible range
+   of values.
+
+   Note that some systems might support ancillary data without
+   providing this function.  Also note that setting the buffer size
+   using the results of this function may not precisely limit the
+   amount of ancillary data that can be received, since additional
+   data may be able to fit into the padding area.
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
 .. function:: getdefaulttimeout()
 
    Return the default timeout in floating seconds for new socket objects. A value
@@ -663,6 +701,109 @@
    to zero. (The format of *address* depends on the address family --- see above.)
 
 
+.. method:: socket.recvmsg(bufsize[, ancbufsize[, flags]])
+
+   Receive normal data (up to *bufsize* bytes) and ancillary data from
+   the socket.  The *ancbufsize* argument sets the size in bytes of
+   the internal buffer used to receive the ancillary data; it defaults
+   to 0, meaning that no ancillary data will be received.  Appropriate
+   buffer sizes for ancillary data can be calculated using
+   :func:`CMSG_SPACE` or :func:`CMSG_LEN`, and items which do not fit
+   into the buffer might be truncated or discarded.  The *flags*
+   argument defaults to 0 and has the same meaning as for
+   :meth:`recv`.
+
+   The return value is a 4-tuple: ``(data, ancdata, msg_flags,
+   address)``.  The *data* item is a :class:`bytes` object holding the
+   non-ancillary data received.  The *ancdata* item is a list of zero
+   or more tuples ``(cmsg_level, cmsg_type, cmsg_data)`` representing
+   the ancillary data (control messages) received: *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   :class:`bytes` object holding the associated data.  The *msg_flags*
+   item is the bitwise OR of various flags indicating conditions on
+   the received message; see your system documentation for details.
+   If the receiving socket is unconnected, *address* is the address of
+   the sending socket, if available; otherwise, its value is
+   unspecified.
+
+   On some systems, :meth:`sendmsg` and :meth:`recvmsg` can be used to
+   pass file descriptors between processes over an :const:`AF_UNIX`
+   socket.  When this facility is used (it is often restricted to
+   :const:`SOCK_STREAM` sockets), :meth:`recvmsg` will return, in its
+   ancillary data, items of the form ``(socket.SOL_SOCKET,
+   socket.SCM_RIGHTS, fds)``, where *fds* is a :class:`bytes` object
+   representing the new file descriptors as a binary array of the
+   native C :ctype:`int` type.  If :meth:`recvmsg` raises an exception
+   after the system call returns, it will first attempt to close any
+   file descriptors received via this mechanism.
+
+   Some systems do not indicate the truncated length of ancillary data
+   items which have been only partially received.  If an item appears
+   to extend beyond the end of the buffer, :meth:`recvmsg` will issue
+   a :exc:`RuntimeWarning`, and will return the part of it which is
+   inside the buffer provided it has not been truncated before the
+   start of its associated data.
+
+   On systems which support the :const:`SCM_RIGHTS` mechanism, the
+   following function will receive up to *maxfds* file descriptors,
+   returning the message data and a list containing the descriptors
+   (while ignoring unexpected conditions such as unrelated control
+   messages being received).  See also :meth:`sendmsg`. ::
+
+      import socket, array
+
+      def recv_fds(sock, msglen, maxfds):
+          fds = array.array("i")   # Array of ints
+          msg, ancdata, flags, addr = sock.recvmsg(msglen, socket.CMSG_LEN(maxfds * fds.itemsize))
+          for cmsg_level, cmsg_type, cmsg_data in ancdata:
+              if (cmsg_level == socket.SOL_SOCKET and cmsg_type == socket.SCM_RIGHTS):
+                  # Append data, ignoring any truncated integers at the end.
+                  fds.fromstring(cmsg_data[:len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+          return msg, list(fds)
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
+.. method:: socket.recvmsg_into(buffers[, ancbufsize[, flags]])
+
+   Receive normal data and ancillary data from the socket, behaving as
+   :meth:`recvmsg` would, but scatter the non-ancillary data into a
+   series of buffers instead of returning a new bytes object.  The
+   *buffers* argument must be an iterable of objects that export
+   writable buffers (e.g. :class:`bytearray` objects); these will be
+   filled with successive chunks of the non-ancillary data until it
+   has all been written or there are no more buffers.  The operating
+   system may set a limit (:func:`~os.sysconf` value ``SC_IOV_MAX``)
+   on the number of buffers that can be used.  The *ancbufsize* and
+   *flags* arguments have the same meaning as for :meth:`recvmsg`.
+
+   The return value is a 4-tuple: ``(nbytes, ancdata, msg_flags,
+   address)``, where *nbytes* is the total number of bytes of
+   non-ancillary data written into the buffers, and *ancdata*,
+   *msg_flags* and *address* are the same as for :meth:`recvmsg`.
+
+   Example::
+
+      >>> import socket
+      >>> s1, s2 = socket.socketpair()
+      >>> b1 = bytearray(b'----')
+      >>> b2 = bytearray(b'0123456789')
+      >>> b3 = bytearray(b'--------------')
+      >>> s1.send(b'Mary had a little lamb')
+      22
+      >>> s2.recvmsg_into([b1, memoryview(b2)[2:9], b3])
+      (22, [], 0, None)
+      >>> [b1, b2, b3]
+      [bytearray(b'Mary'), bytearray(b'01 had a 9'), bytearray(b'little lamb---')]
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.recvfrom_into(buffer[, nbytes[, flags]])
 
    Receive data from the socket, writing it into *buffer* instead of creating a
@@ -710,6 +851,41 @@
    above.)
 
 
+.. method:: socket.sendmsg(buffers[, ancdata[, flags[, address]]])
+
+   Send normal and ancillary data to the socket, gathering the
+   non-ancillary data from a series of buffers and concatenating it
+   into a single message.  The *buffers* argument specifies the
+   non-ancillary data as an iterable of buffer-compatible objects
+   (e.g. :class:`bytes` objects); the operating system may set a limit
+   (:func:`~os.sysconf` value ``SC_IOV_MAX``) on the number of buffers
+   that can be used.  The *ancdata* argument specifies the ancillary
+   data (control messages) as an iterable of zero or more tuples
+   ``(cmsg_level, cmsg_type, cmsg_data)``, where *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   buffer-compatible object holding the associated data.  Note that
+   some systems (in particular, systems without :func:`CMSG_SPACE`)
+   might support sending only one control message per call.  The
+   *flags* argument defaults to 0 and has the same meaning as for
+   :meth:`send`.  If *address* is supplied and not ``None``, it sets a
+   destination address for the message.  The return value is the
+   number of bytes of non-ancillary data sent.
+
+   The following function sends the list of file descriptors *fds*
+   over an :const:`AF_UNIX` socket, on systems which support the
+   :const:`SCM_RIGHTS` mechanism.  See also :meth:`recvmsg`. ::
+
+      import socket, array
+
+      def send_fds(sock, msg, fds):
+          return sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, array.array("i", fds))])
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.setblocking(flag)
 
    Set blocking or non-blocking mode of the socket: if *flag* is 0, the socket is
Index: Lib/ssl.py
===================================================================
--- Lib/ssl.py	(revision 87092)
+++ Lib/ssl.py	(working copy)
@@ -336,6 +336,14 @@
         else:
             return socket.sendto(self, data, flags_or_addr, addr)
 
+    def sendmsg(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("sendmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.sendmsg(self, *args, **kwargs)
+
     def sendall(self, data, flags=0):
         self._checkClosed()
         if self._sslobj:
@@ -394,6 +402,22 @@
         else:
             return socket.recvfrom_into(self, buffer, nbytes, flags)
 
+    def recvmsg(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("recvmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.recvmsg(self, *args, **kwargs)
+
+    def recvmsg_into(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("recvmsg_into not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.recvmsg_into(self, *args, **kwargs)
+
     def pending(self):
         self._checkClosed()
         if self._sslobj:
Index: Lib/test/test_ssl.py
===================================================================
--- Lib/test/test_ssl.py	(revision 87092)
+++ Lib/test/test_ssl.py	(working copy)
@@ -1388,17 +1388,30 @@
                     count, addr = s.recvfrom_into(b)
                     return b[:count]
 
+                def _recvmsg(*args, **kwargs):
+                    return s.recvmsg(*args, **kwargs)[0]
+
+                def _recvmsg_into(bufsize, *args, **kwargs):
+                    b = bytearray(bufsize)
+                    return bytes(b[:s.recvmsg_into([b], *args, **kwargs)[0]])
+
+                def _sendmsg(msg, *args, **kwargs):
+                    return s.sendmsg([msg])
+
                 # (name, method, whether to expect success, *args)
                 send_methods = [
                     ('send', s.send, True, []),
                     ('sendto', s.sendto, False, ["some.address"]),
+                    ('sendmsg', _sendmsg, False, []),
                     ('sendall', s.sendall, True, []),
                 ]
                 recv_methods = [
                     ('recv', s.recv, True, []),
                     ('recvfrom', s.recvfrom, False, ["some.address"]),
+                    ('recvmsg', _recvmsg, False, [100]),
                     ('recv_into', _recv_into, True, []),
                     ('recvfrom_into', _recvfrom_into, False, []),
+                    ('recvmsg_into', _recvmsg_into, False, [100]),
                 ]
                 data_prefix = "PREFIX_"
 
Index: Lib/test/test_socket.py
===================================================================
--- Lib/test/test_socket.py	(revision 87092)
+++ Lib/test/test_socket.py	(working copy)
@@ -7,6 +7,8 @@
 import io
 import socket
 import select
+import tempfile
+import _testcapi
 import time
 import traceback
 import queue
@@ -54,6 +56,9 @@
     thread = None
     threading = None
 
+# Size in bytes of the int type
+SIZEOF_INT = array.array("i").itemsize
+
 class SocketTCPTest(unittest.TestCase):
 
     def setUp(self):
@@ -75,6 +80,26 @@
         self.serv.close()
         self.serv = None
 
+class ThreadSafeCleanupTestCase(unittest.TestCase):
+    """Subclass of unittest.TestCase with thread-safe cleanup methods.
+
+    This subclass protects the addCleanup() and doCleanups() methods
+    with a recursive lock.
+    """
+
+    if threading:
+        def __init__(self, *args, **kwargs):
+            super().__init__(*args, **kwargs)
+            self._cleanup_lock = threading.RLock()
+
+        def addCleanup(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super().addCleanup(*args, **kwargs)
+
+        def doCleanups(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super().doCleanups(*args, **kwargs)
+
 class ThreadableTest:
     """Threadable Test class
 
@@ -257,6 +282,243 @@
         ThreadableTest.clientTearDown(self)
 
 
+# The following classes are used by the sendmsg()/recvmsg() tests.
+# Combining, for instance, ConnectedStreamTestMixin and TCPTestBase
+# gives a drop-in replacement for SocketConnectedTest, but different
+# address families can be used, and the attributes serv_addr and
+# cli_addr will be set to the addresses of the endpoints.
+
+class SocketTestBase(unittest.TestCase):
+    """A base class for socket tests.
+
+    Subclasses must provide methods newSocket() to return a new socket
+    and bindSock(sock) to bind it to an unused address.
+
+    Creates a socket self.serv and sets self.serv_addr to its address.
+    """
+
+    def setUp(self):
+        self.serv = self.newSocket()
+        self.bindServer()
+
+    def bindServer(self):
+        """Bind server socket and set self.serv_addr to its address."""
+        self.bindSock(self.serv)
+        self.serv_addr = self.serv.getsockname()
+
+    def tearDown(self):
+        self.serv.close()
+        self.serv = None
+
+
+class SocketListeningTestMixin(SocketTestBase):
+    """Mixin to listen on the server socket."""
+
+    def setUp(self):
+        super().setUp()
+        self.serv.listen(1)
+
+
+class ThreadedSocketTestMixin(ThreadSafeCleanupTestCase, SocketTestBase,
+                              ThreadableTest):
+    """Mixin to add client socket and allow client/server tests.
+
+    Client socket is self.cli and its address is self.cli_addr.  See
+    ThreadableTest for usage information.
+    """
+
+    def __init__(self, *args, **kwargs):
+        super().__init__(*args, **kwargs)
+        ThreadableTest.__init__(self)
+
+    def clientSetUp(self):
+        self.cli = self.newClientSocket()
+        self.bindClient()
+
+    def newClientSocket(self):
+        """Return a new socket for use as client."""
+        return self.newSocket()
+
+    def bindClient(self):
+        """Bind client socket and set self.cli_addr to its address."""
+        self.bindSock(self.cli)
+        self.cli_addr = self.cli.getsockname()
+
+    def clientTearDown(self):
+        self.cli.close()
+        self.cli = None
+        ThreadableTest.clientTearDown(self)
+
+
+class ConnectedStreamTestMixin(SocketListeningTestMixin,
+                               ThreadedSocketTestMixin):
+    """Mixin to allow client/server stream tests with connected client.
+
+    Server's socket representing connection to client is self.cli_conn
+    and client's connection to server is self.serv_conn.  (Based on
+    SocketConnectedTest.)
+    """
+
+    def setUp(self):
+        super().setUp()
+        # Indicate explicitly we're ready for the client thread to
+        # proceed and then perform the blocking call to accept
+        self.serverExplicitReady()
+        conn, addr = self.serv.accept()
+        self.cli_conn = conn
+
+    def tearDown(self):
+        self.cli_conn.close()
+        self.cli_conn = None
+        super().tearDown()
+
+    def clientSetUp(self):
+        super().clientSetUp()
+        self.cli.connect(self.serv_addr)
+        self.serv_conn = self.cli
+
+    def clientTearDown(self):
+        self.serv_conn.close()
+        self.serv_conn = None
+        super().clientTearDown()
+
+
+class UnixSocketTestBase(SocketTestBase):
+    """Base class for Unix-domain socket tests."""
+
+    # This class is used for file descriptor passing tests, so we
+    # create the sockets in a private directory so that other users
+    # can't send anything that might be problematic for a privileged
+    # user running the tests.
+
+    def setUp(self):
+        self.dir_path = tempfile.mkdtemp()
+        self.addCleanup(os.rmdir, self.dir_path)
+        super().setUp()
+
+    def bindSock(self, sock):
+        path = tempfile.mktemp(dir=self.dir_path)
+        sock.bind(path)
+        self.addCleanup(support.unlink, path)
+
+class UnixStreamBase(UnixSocketTestBase):
+    """Base class for Unix-domain SOCK_STREAM tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+
+
+class InetTestBase(SocketTestBase):
+    """Base class for IPv4 socket tests."""
+
+    host = HOST
+
+    def setUp(self):
+        super().setUp()
+        self.port = self.serv_addr[1]
+
+    def bindSock(self, sock):
+        support.bind_port(sock, host=self.host)
+
+class TCPTestBase(InetTestBase):
+    """Base class for TCP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+
+class UDPTestBase(InetTestBase):
+    """Base class for UDP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+
+class SCTPStreamBase(InetTestBase):
+    """Base class for SCTP tests in one-to-one (SOCK_STREAM) mode."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM,
+                             socket.IPPROTO_SCTP)
+
+
+class Inet6TestBase(InetTestBase):
+    """Base class for IPv6 socket tests."""
+
+    # Don't use "localhost" here - it may not have an IPv6 address
+    # assigned to it by default (e.g. in /etc/hosts), and if someone
+    # has assigned it an IPv4-mapped address, then it's unlikely to
+    # work with the full IPv6 API.
+    host = "::1"
+
+class UDP6TestBase(Inet6TestBase):
+    """Base class for UDP-over-IPv6 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
+
+
+# Test-skipping decorators for use with ThreadableTest.
+
+def skipWithClientIf(condition, reason):
+    """Skip decorated test if condition is true, add client_skip decorator.
+
+    If the decorated object is not a class, sets its attribute
+    "client_skip" to a decorator which will return an empty function
+    if the test is to be skipped, or the original function if it is
+    not.  This can be used to avoid running the client part of a
+    skipped test when using ThreadableTest.
+    """
+    def client_pass(*args, **kwargs):
+        pass
+    def skipdec(obj):
+        retval = unittest.skip(reason)(obj)
+        if not isinstance(obj, type):
+            retval.client_skip = lambda f: client_pass
+        return retval
+    def noskipdec(obj):
+        if not (isinstance(obj, type) or hasattr(obj, "client_skip")):
+            obj.client_skip = lambda f: f
+        return obj
+    return skipdec if condition else noskipdec
+
+
+def requireAttrs(obj, *attributes):
+    """Skip decorated test if obj is missing any of the given attributes.
+
+    Sets client_skip attribute as skipWithClientIf() does.
+    """
+    missing = [name for name in attributes if not hasattr(obj, name)]
+    return skipWithClientIf(
+        missing, "don't have " + ", ".join(name for name in missing))
+
+
+def requireSocket(*args):
+    """Skip decorated test if a socket cannot be created with given arguments.
+
+    When an argument is given as a string, will use the value of that
+    attribute of the socket module, or skip the test if it doesn't
+    exist.  Sets client_skip attribute as skipWithClientIf() does.
+    """
+    err = None
+    missing = [obj for obj in args if
+               isinstance(obj, str) and not hasattr(socket, obj)]
+    if missing:
+        err = "don't have " + ", ".join(name for name in missing)
+    else:
+        callargs = [getattr(socket, obj) if isinstance(obj, str) else obj
+                    for obj in args]
+        try:
+            s = socket.socket(*callargs)
+        except socket.error as e:
+            # XXX: check errno?
+            err = str(e)
+        else:
+            s.close()
+    return skipWithClientIf(
+        err is not None,
+        "can't create socket({0}): {1}".format(
+            ", ".join(str(o) for o in args), err))
+
+
 #######################################################################
 ## Begin Tests
 
@@ -875,7 +1137,1840 @@
     def _testRecvFromNegative(self):
         self.cli.sendto(MSG, 0, (HOST, self.port))
 
+
+# Tests for the sendmsg()/recvmsg() interface.  Where possible, the
+# same test code is used with different families and types of socket
+# (e.g. stream, datagram), and tests using recvmsg() are repeated
+# using recvmsg_into().
+#
+# The generic test classes such as SendmsgTests and
+# RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
+# supplied with sockets cli_sock and serv_sock representing the
+# client's and the server's end of the connection respectively, and
+# attributes cli_addr and serv_addr holding their (numeric where
+# appropriate) addresses.
+#
+# The final concrete test classes combine these with subclasses of
+# SocketTestBase which set up client and server sockets of a specific
+# type, and with subclasses of SendrecvmsgBase such as
+# SendrecvmsgDgramBase and SendrecvmsgConnectedBase which map these
+# sockets to cli_sock and serv_sock and override the methods and
+# attributes of SendrecvmsgBase to fill in destination addresses if
+# needed when sending, check for specific flags in msg_flags, etc.
+#
+# RecvmsgIntoMixin provides a version of doRecvmsg() implemented using
+# recvmsg_into().
+
+# XXX: like the other datagram (UDP) tests in this module, the code
+# here assumes that datagram delivery on the local machine will be
+# reliable.
+
+class SendrecvmsgBase(ThreadSafeCleanupTestCase):
+    # Base class for sendmsg()/recvmsg() tests.
+
+    # Time in seconds to wait before considering a test failed, or
+    # None for no timeout.  Not all tests actually set a timeout.
+    fail_timeout = 3.0
+
+    def setUp(self):
+        self.misc_event = threading.Event()
+        super().setUp()
+
+    def sendToServer(self, msg):
+        # Send msg to the server.
+        return self.cli_sock.send(msg)
+
+    # Tuple of alternative default arguments for sendmsg() when called
+    # via sendmsgToServer() (e.g. to include a destination address).
+    sendmsg_to_server_defaults = ()
+
+    def sendmsgToServer(self, *args):
+        # Call sendmsg() on self.cli_sock with the given arguments,
+        # filling in any arguments which are not supplied with the
+        # corresponding items of self.sendmsg_to_server_defaults, if
+        # any.
+        return self.cli_sock.sendmsg(
+            *(args + self.sendmsg_to_server_defaults[len(args):]))
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        # Call recvmsg() on sock with given arguments and return its
+        # result.  Should be used for tests which can use either
+        # recvmsg() or recvmsg_into() - RecvmsgIntoMixin overrides
+        # this method with one which emulates it using recvmsg_into(),
+        # thus allowing the same test to be used for both methods.
+        result = sock.recvmsg(bufsize, *args)
+        self.registerRecvmsgResult(result)
+        return result
+
+    def registerRecvmsgResult(self, result):
+        # Called by doRecvmsg() with the return value of recvmsg() or
+        # recvmsg_into().  Can be overridden to arrange cleanup based
+        # on the returned ancillary data, for instance.
+        pass
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Called to compare the received address with the address of
+        # the peer.
+        self.assertEqual(addr1, addr2)
+
+    # Flags that are normally unset in msg_flags
+    msg_flags_common_unset = 0
+    for name in ("MSG_CTRUNC", "MSG_OOB"):
+        msg_flags_common_unset |= getattr(socket, name, 0)
+
+    # Flags that are normally set
+    msg_flags_common_set = 0
+
+    # Flags set when a complete record has been received (e.g. MSG_EOR
+    # for SCTP)
+    msg_flags_eor_indicator = 0
+
+    # Flags set when a complete record has not been received
+    # (e.g. MSG_TRUNC for datagram sockets)
+    msg_flags_non_eor_indicator = 0
+
+    def checkFlags(self, flags, eor=None, checkset=0, checkunset=0, ignore=0):
+        # Method to check the value of msg_flags returned by recvmsg[_into]().
+        #
+        # Checks that all bits in msg_flags_common_set attribute are
+        # set in "flags" and all bits in msg_flags_common_unset are
+        # unset.
+        #
+        # The "eor" argument specifies whether the flags should
+        # indicate that a full record (or datagram) has been received.
+        # If "eor" is None, no checks are done; otherwise, checks
+        # that:
+        #
+        #  * if "eor" is true, all bits in msg_flags_eor_indicator are
+        #    set and all bits in msg_flags_non_eor_indicator are unset
+        #
+        #  * if "eor" is false, all bits in msg_flags_non_eor_indicator
+        #    are set and all bits in msg_flags_eor_indicator are unset
+        #
+        # If "checkset" and/or "checkunset" are supplied, they require
+        # the given bits to be set or unset respectively, overriding
+        # what the attributes require for those bits.
+        #
+        # If any bits are set in "ignore", they will not be checked,
+        # regardless of the other inputs.
+        #
+        # Will raise Exception if the inputs require a bit to be both
+        # set and unset, and it is not ignored.
+
+        defaultset = self.msg_flags_common_set
+        defaultunset = self.msg_flags_common_unset
+
+        if eor:
+            defaultset |= self.msg_flags_eor_indicator
+            defaultunset |= self.msg_flags_non_eor_indicator
+        elif eor is not None:
+            defaultset |= self.msg_flags_non_eor_indicator
+            defaultunset |= self.msg_flags_eor_indicator
+
+        # Function arguments override defaults
+        defaultset &= ~checkunset
+        defaultunset &= ~checkset
+
+        # Merge arguments with remaining defaults, and check for conflicts
+        checkset |= defaultset
+        checkunset |= defaultunset
+        inboth = checkset & checkunset & ~ignore
+        if inboth:
+            raise Exception("contradictory set, unset requirements for flags "
+                            "{0:#x}".format(inboth))
+
+        # Compare with given msg_flags value
+        mask = (checkset | checkunset) & ~ignore
+        self.assertEqual(flags & mask, checkset & mask)
+
+
+class RecvmsgIntoMixin(SendrecvmsgBase):
+    # Mixin to implement doRecvmsg() using recvmsg_into().
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        buf = bytearray(bufsize)
+        result = sock.recvmsg_into([buf], *args)
+        self.registerRecvmsgResult(result)
+        self.assertGreaterEqual(result[0], 0)
+        self.assertLessEqual(result[0], bufsize)
+        return (bytes(buf[:result[0]]),) + result[1:]
+
+
+class SendrecvmsgDgramFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for datagram sockets.
+
+    @property
+    def msg_flags_non_eor_indicator(self):
+        return super().msg_flags_non_eor_indicator | socket.MSG_TRUNC
+
+
+class SendrecvmsgSCTPFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for SCTP sockets.
+
+    @property
+    def msg_flags_eor_indicator(self):
+        return super().msg_flags_eor_indicator | socket.MSG_EOR
+
+
+class SendrecvmsgConnectionlessBase(SendrecvmsgBase):
+    # Base class for tests on connectionless-mode sockets.  Users must
+    # supply sockets on attributes cli and serv to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.serv
+
+    @property
+    def cli_sock(self):
+        return self.cli
+
+    @property
+    def sendmsg_to_server_defaults(self):
+        return ([], [], 0, self.serv_addr)
+
+    def sendToServer(self, msg):
+        return self.cli_sock.sendto(msg, self.serv_addr)
+
+
+class SendrecvmsgConnectedBase(SendrecvmsgBase):
+    # Base class for tests on connected sockets.  Users must supply
+    # sockets on attributes serv_conn and cli_conn (representing the
+    # connections *to* the server and the client), to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.cli_conn
+
+    @property
+    def cli_sock(self):
+        return self.serv_conn
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Address is currently "unspecified" for a connected socket,
+        # so we don't examine it
+        pass
+
+
+class SendrecvmsgServerTimeoutBase(SendrecvmsgBase):
+    # Base class to set a timeout on server's socket.
+
+    def setUp(self):
+        super().setUp()
+        self.serv_sock.settimeout(self.fail_timeout)
+
+
+class SendmsgTests(SendrecvmsgServerTimeoutBase):
+    # Tests for sendmsg() which can use any socket type and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsg(self):
+        # Send a simple message with sendmsg().
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG]), len(MSG))
+
+    def testSendmsgDataGenerator(self):
+        # Send from buffer obtained from a generator (not a sequence).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgDataGenerator(self):
+        self.assertEqual(self.sendmsgToServer((o for o in [MSG])),
+                         len(MSG))
+
+    def testSendmsgAncillaryGenerator(self):
+        # Gather (empty) ancillary data from a generator.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgAncillaryGenerator(self):
+        self.assertEqual(self.sendmsgToServer([MSG], (o for o in [])),
+                         len(MSG))
+
+    def testSendmsgArray(self):
+        # Send data from an array instead of the usual bytes object.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgArray(self):
+        self.assertEqual(self.sendmsgToServer([array.array("B", MSG)]),
+                         len(MSG))
+
+    def testSendmsgGather(self):
+        # Send message data from more than one buffer (gather write).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgGather(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+    def testSendmsgBadArgs(self):
+        # Check that sendmsg() rejects invalid arguments.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadArgs(self):
+        self.assertRaises(TypeError, self.cli_sock.sendmsg)
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          b"not in an iterable")
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG, object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], 0, object())
+        self.sendToServer(b"done")
+
+    def testSendmsgBadCmsg(self):
+        # Check that invalid ancillary data items are rejected.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(object(), 0, b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, object(), b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, object())])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0)])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b"data", 42)])
+        self.sendToServer(b"done")
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testSendmsgBadMultiCmsg(self):
+        # Check that invalid ancillary data items are rejected when
+        # more than one item is present.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    @testSendmsgBadMultiCmsg.client_skip
+    def _testSendmsgBadMultiCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [0, 0, b""])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b""), object()])
+        self.sendToServer(b"done")
+
+    def testSendmsgExcessCmsgReject(self):
+        # Check that sendmsg() rejects excess ancillary data items
+        # when the number that can be sent is limited.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgExcessCmsgReject(self):
+        if not hasattr(socket, "CMSG_SPACE"):
+            # Can only send one item
+            with self.assertRaises(socket.error) as cm:
+                self.sendmsgToServer([MSG], [(0, 0, b""), (0, 0, b"")])
+            self.assertIsNone(cm.exception.errno)
+        self.sendToServer(b"done")
+
+    def testSendmsgAfterClose(self):
+        # Check that sendmsg() fails on a closed socket.
+        pass
+
+    def _testSendmsgAfterClose(self):
+        self.cli_sock.close()
+        self.assertRaises(socket.error, self.sendmsgToServer, [MSG])
+
+
+class SendmsgStreamTests(SendmsgTests):
+    # Tests for sendmsg() which require a stream socket and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsgExplicitNoneAddr(self):
+        # Check that peer address can be specified as None.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgExplicitNoneAddr(self):
+        self.assertEqual(self.sendmsgToServer([MSG], [], 0, None), len(MSG))
+
+    def testSendmsgTimeout(self):
+        # Check that timeout works with sendmsg().
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    def _testSendmsgTimeout(self):
+        try:
+            self.cli_sock.settimeout(0.03)
+            with self.assertRaises(socket.timeout):
+                while True:
+                    self.sendmsgToServer([b"a"*512])
+        finally:
+            self.misc_event.set()
+
+    # XXX: would be nice to have more tests for sendmsg flags argument.
+
+    # Linux supports MSG_DONTWAIT when sending, but in general, it
+    # only works when receiving.  Could add other platforms if they
+    # support it too.
+    @skipWithClientIf(sys.platform not in {"linux2"},
+                      "MSG_DONTWAIT not known to work on this platform when "
+                      "sending")
+    def testSendmsgDontWait(self):
+        # Check that MSG_DONTWAIT in flags causes non-blocking behaviour.
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @testSendmsgDontWait.client_skip
+    def _testSendmsgDontWait(self):
+        try:
+            with self.assertRaises(socket.error) as cm:
+                while True:
+                    self.sendmsgToServer([b"a"*512], [], socket.MSG_DONTWAIT)
+            self.assertIn(cm.exception.errno,
+                          (errno.EAGAIN, errno.EWOULDBLOCK))
+        finally:
+            self.misc_event.set()
+
+
+class SendmsgConnectionlessTests(SendmsgTests):
+    # Tests for sendmsg() which require a connectionless-mode
+    # (e.g. datagram) socket, and do not involve recvmsg() or
+    # recvmsg_into().
+
+    def testSendmsgNoDestAddr(self):
+        # Check that sendmsg() fails when no destination address is
+        # given for unconnected socket.
+        pass
+
+    def _testSendmsgNoDestAddr(self):
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG])
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG], [], 0, None)
+
+
+class RecvmsgGenericTests(SendrecvmsgBase):
+    # Tests for recvmsg() which can also be emulated using
+    # recvmsg_into(), and can use any socket type.
+
+    def testRecvmsg(self):
+        # Receive a simple message with recvmsg[_into]().
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsg(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgExplicitDefaults(self):
+        # Test recvmsg[_into]() with default arguments provided explicitly.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgExplicitDefaults(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShorter(self):
+        # Receive a message smaller than buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) + 42)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShorter(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgTrunc(self):
+        # Receive part of message, check for truncation indicators.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+    def _testRecvmsgTrunc(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShortAncillaryBuf(self):
+        # Test ancillary data buffer too small to hold any ancillary data.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 1)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShortAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgLongAncillaryBuf(self):
+        # Test large ancillary data buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgLongAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgAfterClose(self):
+        # Check that recvmsg[_into]() fails on a closed socket.
+        self.serv_sock.close()
+        self.assertRaises(socket.error, self.doRecvmsg, self.serv_sock, 1024)
+
+    def _testRecvmsgAfterClose(self):
+        pass
+
+    def testRecvmsgTimeout(self):
+        # Check that timeout works.
+        try:
+            self.serv_sock.settimeout(0.03)
+            self.assertRaises(socket.timeout,
+                              self.doRecvmsg, self.serv_sock, len(MSG))
+        finally:
+            self.misc_event.set()
+
+    def _testRecvmsgTimeout(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @requireAttrs(socket, "MSG_PEEK")
+    def testRecvmsgPeek(self):
+        # Check that MSG_PEEK in flags enables examination of pending
+        # data without consuming it.
+
+        # Receive part of data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3, 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        # Ignoring MSG_TRUNC here (so this test is the same for stream
+        # and datagram sockets).  Some wording in POSIX seems to
+        # suggest that it needn't be set when peeking, but that may
+        # just be a slip.
+        self.checkFlags(flags, eor=False,
+                        ignore=getattr(socket, "MSG_TRUNC", 0))
+
+        # Receive all data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        # Check that the same data can still be received normally.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgPeek.client_skip
+    def _testRecvmsgPeek(self):
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testRecvmsgFromSendmsg(self):
+        # Test receiving with recvmsg[_into]() when message is sent
+        # using sendmsg().
+        self.serv_sock.settimeout(self.fail_timeout)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgFromSendmsg.client_skip
+    def _testRecvmsgFromSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+
+class RecvmsgGenericStreamTests(RecvmsgGenericTests):
+    # Tests which require a stream socket and can use either recvmsg()
+    # or recvmsg_into().
+
+    def testRecvmsgEOF(self):
+        # Receive end-of-stream indicator (b"", peer socket closed).
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.assertEqual(msg, b"")
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=None) # Might not have end-of-record marker
+
+    def _testRecvmsgEOF(self):
+        self.cli_sock.close()
+
+    def testRecvmsgOverflow(self):
+        # Receive a message in more than one chunk.
+        seg1, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                    len(MSG) - 3)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+        seg2, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        msg = seg1 + seg2
+        self.assertEqual(msg, MSG)
+
+    def _testRecvmsgOverflow(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgTests(RecvmsgGenericTests):
+    # Tests for recvmsg() which can use any socket type.
+
+    def testRecvmsgBadArgs(self):
+        # Check that recvmsg() rejects invalid arguments.
+        self.assertRaises(TypeError, self.serv_sock.recvmsg)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          -1, 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          len(MSG), -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          [bytearray(10)], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          object(), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), 0, object())
+
+        msg, ancdata, flags, addr = self.serv_sock.recvmsg(len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgBadArgs(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgIntoTests(RecvmsgIntoMixin, RecvmsgGenericTests):
+    # Tests for recvmsg_into() which can use any socket type.
+
+    def testRecvmsgIntoBadArgs(self):
+        # Check that recvmsg_into() rejects invalid arguments.
+        buf = bytearray(len(MSG))
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          len(MSG), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          buf, 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [object()], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [b"I'm not writable"], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf, object()], 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg_into,
+                          [buf], -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], 0, object())
+
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf], 0, 0)
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoBadArgs(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoGenerator(self):
+        # Receive into buffer obtained from a generator (not a sequence).
+        buf = bytearray(len(MSG))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            (o for o in [buf]))
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoGenerator(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoArray(self):
+        # Receive into an array rather than the usual bytearray.
+        buf = array.array("B", bytes(len(MSG)))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf])
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf.tostring(), MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoArray(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoScatter(self):
+        # Receive into multiple buffers (scatter write).
+        b1 = bytearray(b"----")
+        b2 = bytearray(b"0123456789")
+        b3 = bytearray(b"--------------")
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            [b1, memoryview(b2)[2:9], b3])
+        self.assertEqual(nbytes, len(b"Mary had a little lamb"))
+        self.assertEqual(b1, bytearray(b"Mary"))
+        self.assertEqual(b2, bytearray(b"01 had a 9"))
+        self.assertEqual(b3, bytearray(b"little lamb---"))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoScatter(self):
+        self.sendToServer(b"Mary had a little lamb")
+
+
+class CmsgMacroTests(unittest.TestCase):
+    # Test the functions CMSG_LEN() and CMSG_SPACE().  Tests
+    # assumptions used by sendmsg() and recvmsg[_into](), which share
+    # code with these functions.
+
+    # Match the definition in socketmodule.c
+    socklen_t_limit = min(0x7fffffff, _testcapi.INT_MAX)
+
+    @requireAttrs(socket, "CMSG_LEN")
+    def testCMSG_LEN(self):
+        # Test CMSG_LEN() with various valid and invalid values,
+        # checking the assumptions used by recvmsg() and sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_LEN(0) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(socket.CMSG_LEN(0), array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_LEN(n)
+            # This is how recvmsg() calculates the data size
+            self.assertEqual(ret - socket.CMSG_LEN(0), n)
+            self.assertLessEqual(ret, self.socklen_t_limit)
+
+        self.assertRaises(OverflowError, socket.CMSG_LEN, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_LEN, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_LEN, sys.maxsize)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testCMSG_SPACE(self):
+        # Test CMSG_SPACE() with various valid and invalid values,
+        # checking the assumptions used by sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_SPACE(1) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        last = socket.CMSG_SPACE(0)
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(last, array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_SPACE(n)
+            self.assertGreaterEqual(ret, last)
+            self.assertGreaterEqual(ret, socket.CMSG_LEN(n))
+            self.assertGreaterEqual(ret, n + socket.CMSG_LEN(0))
+            self.assertLessEqual(ret, self.socklen_t_limit)
+            last = ret
+
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, sys.maxsize)
+
+
+class SCMRightsTest(SendrecvmsgServerTimeoutBase):
+    # Tests for file descriptor passing on Unix-domain sockets.
+
+    # Invalid file descriptor value that's unlikely to evaluate to a
+    # real FD even if one of its bytes is replaced with a different
+    # value (which shouldn't actually happen).
+    badfd = -0x5555
+
+    def newFDs(self, n):
+        # Return a list of n file descriptors for newly-created files
+        # containing their list indices as ASCII numbers.
+        fds = []
+        for i in range(n):
+            fd, path = tempfile.mkstemp()
+            self.addCleanup(os.unlink, path)
+            self.addCleanup(os.close, fd)
+            os.write(fd, str(i).encode())
+            fds.append(fd)
+        return fds
+
+    def checkFDs(self, fds):
+        # Check that the file descriptors in the given list contain
+        # their correct list indices as ASCII numbers.
+        for n, fd in enumerate(fds):
+            os.lseek(fd, 0, os.SEEK_SET)
+            self.assertEqual(os.read(fd, 1024), str(n).encode())
+
+    def registerRecvmsgResult(self, result):
+        self.addCleanup(self.closeRecvmsgFDs, result)
+
+    def closeRecvmsgFDs(self, recvmsg_result):
+        # Close all file descriptors specified in the ancillary data
+        # of the given return value from recvmsg() or recvmsg_into().
+        for cmsg_level, cmsg_type, cmsg_data in recvmsg_result[1]:
+            if (cmsg_level == socket.SOL_SOCKET and
+                    cmsg_type == socket.SCM_RIGHTS):
+                fds = array.array("i")
+                fds.fromstring(cmsg_data[:
+                        len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+                for fd in fds:
+                    os.close(fd)
+
+    def createAndSendFDs(self, n):
+        # Send n new file descriptors created by newFDs() to the
+        # server, with the constant MSG as the non-ancillary data.
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.SOL_SOCKET,
+                                   socket.SCM_RIGHTS,
+                                   array.array("i", self.newFDs(n)))]),
+            len(MSG))
+
+    def checkRecvmsgFDs(self, numfds, result, maxcmsgs=1, ignoreflags=0):
+        # Check that constant MSG was received with numfds file
+        # descriptors in a maximum of maxcmsgs control messages (which
+        # must contain only complete integers).  By default, check
+        # that MSG_CTRUNC is unset, but ignore any flags in
+        # ignoreflags.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertIsInstance(ancdata, list)
+        self.assertLessEqual(len(ancdata), maxcmsgs)
+        fds = array.array("i")
+        for item in ancdata:
+            self.assertIsInstance(item, tuple)
+            cmsg_level, cmsg_type, cmsg_data = item
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertIsInstance(cmsg_data, bytes)
+            self.assertEqual(len(cmsg_data) % SIZEOF_INT, 0)
+            fds.fromstring(cmsg_data)
+
+        self.assertEqual(len(fds), numfds)
+        self.checkFDs(fds)
+
+    def testFDPassSimple(self):
+        # Pass a single FD (array read from bytes object).
+        self.checkRecvmsgFDs(1, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testFDPassSimple(self):
+        self.assertEqual(
+            self.sendmsgToServer(
+                [MSG],
+                [(socket.SOL_SOCKET,
+                  socket.SCM_RIGHTS,
+                  array.array("i", self.newFDs(1)).tostring())]),
+            len(MSG))
+
+    def testMultipleFDPass(self):
+        # Pass multiple FDs in a single array.
+        self.checkRecvmsgFDs(4, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testMultipleFDPass(self):
+        self.createAndSendFDs(4)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassCMSG_SPACE(self):
+        # Test using CMSG_SPACE() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(
+            4, self.doRecvmsg(self.serv_sock, len(MSG),
+                              socket.CMSG_SPACE(4 * SIZEOF_INT)))
+
+    @testFDPassCMSG_SPACE.client_skip
+    def _testFDPassCMSG_SPACE(self):
+        self.createAndSendFDs(4)
+
+    def testFDPassCMSG_LEN(self):
+        # Test using CMSG_LEN() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(1,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_LEN(4 * SIZEOF_INT)),
+                             # RFC 3542 says implementations may set
+                             # MSG_CTRUNC if there isn't enough space
+                             # for trailing padding.
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassCMSG_LEN(self):
+        self.createAndSendFDs(1)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparate(self):
+        # Pass two FDs in two separate arrays.  Arrays may be combined
+        # into a single control message by the OS.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG), 10240),
+                             maxcmsgs=2)
+
+    @testFDPassSeparate.client_skip
+    def _testFDPassSeparate(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparateMinSpace(self):
+        # Pass two FDs in two separate arrays, receiving them into the
+        # minimum space for two arrays.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_SPACE(SIZEOF_INT) +
+                                            socket.CMSG_LEN(SIZEOF_INT)),
+                             maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
+
+    @testFDPassSeparateMinSpace.client_skip
+    def _testFDPassSeparateMinSpace(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    def sendAncillaryIfPossible(self, msg, ancdata):
+        # Try to send msg and ancdata to server, but if the system
+        # call fails, just send msg with no ancillary data.
+        try:
+            nbytes = self.sendmsgToServer([msg], ancdata)
+        except socket.error as e:
+            # Check that it was the system call that failed
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer([msg])
+        self.assertEqual(nbytes, len(msg))
+
+    def testFDPassEmpty(self):
+        # Try to pass an empty FD array.  Can receive either no array
+        # or an empty array.
+        self.checkRecvmsgFDs(0, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240),
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassEmpty(self):
+        self.sendAncillaryIfPossible(MSG, [(socket.SOL_SOCKET,
+                                            socket.SCM_RIGHTS,
+                                            b"")])
+
+    def testFDPassPartialInt(self):
+        # Try to pass a truncated FD array.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 1)
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    def _testFDPassPartialInt(self):
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [self.badfd]).tostring()[:-1])])
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassPartialIntInMiddle(self):
+        # Try to pass two FD arrays, the first of which is truncated.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 2)
+        fds = array.array("i")
+        # Arrays may have been combined in a single control message
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            fds.fromstring(cmsg_data[:
+                    len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.assertLessEqual(len(fds), 2)
+        self.checkFDs(fds)
+
+    @testFDPassPartialIntInMiddle.client_skip
+    def _testFDPassPartialIntInMiddle(self):
+        fd0, fd1 = self.newFDs(2)
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd0, self.badfd]).tostring()[:-1]),
+             (socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd1]))])
+
+    def checkTruncatedHeader(self, result, ignoreflags=0):
+        # Check that no ancillary data items are returned when data is
+        # truncated inside the cmsghdr structure.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no buffer size
+        # is specified.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG)),
+                                  # BSD seems to set MSG_CTRUNC only
+                                  # if an item has been partially
+                                  # received.
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTruncNoBufSize(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc0(self):
+        # Check that no ancillary data is received when buffer size is 0.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 0),
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTrunc0(self):
+        self.createAndSendFDs(1)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    def testCmsgTrunc1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 1))
+
+    def _testCmsgTrunc1(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc2Int(self):
+        # The cmsghdr structure has at least three members, two of
+        # which are ints, so we still shouldn't see any ancillary
+        # data.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 SIZEOF_INT * 2))
+
+    def _testCmsgTrunc2Int(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Minus1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 socket.CMSG_LEN(0) - 1))
+
+    def _testCmsgTruncLen0Minus1(self):
+        self.createAndSendFDs(1)
+
+    # The following tests try to truncate the control message in the
+    # middle of the FD array.
+
+    def checkTruncatedArray(self, ancbuf, maxdata, mindata=0):
+        # Check that file descriptor data is truncated to between
+        # mindata and maxdata bytes when received with buffer size
+        # ancbuf, and that any complete file descriptor numbers are
+        # valid.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbuf)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        if mindata == 0 and ancdata == []:
+            return
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+        self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+        self.assertGreaterEqual(len(cmsg_data), mindata)
+        self.assertLessEqual(len(cmsg_data), maxdata)
+        fds = array.array("i")
+        fds.fromstring(cmsg_data[:
+                len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.checkFDs(fds)
+
+    def testCmsgTruncLen0(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
+
+    def _testCmsgTruncLen0(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Plus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
+
+    def _testCmsgTruncLen0Plus1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(SIZEOF_INT),
+                                 maxdata=SIZEOF_INT)
+
+    def _testCmsgTruncLen1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen2Minus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(2 * SIZEOF_INT) - 1,
+                                 maxdata=(2 * SIZEOF_INT) - 1)
+
+    def _testCmsgTruncLen2Minus1(self):
+        self.createAndSendFDs(2)
+
+
+class RFC3542AncillaryTest(SendrecvmsgServerTimeoutBase):
+    # Test sendmsg() and recvmsg[_into]() using the ancillary data
+    # features of the RFC 3542 Advanced Sockets API for IPv6.
+    # Currently we can only handle certain data items (e.g. traffic
+    # class, hop limit, MTU discovery and fragmentation settings)
+    # without resorting to unportable means such as the struct module,
+    # but the tests here are aimed at testing the ancillary data
+    # handling in sendmsg() and recvmsg() rather than the IPv6 API
+    # itself.
+
+    # Test value to use when setting hop limit of packet
+    hop_limit = 2
+
+    # Test value to use when setting traffic class of packet.
+    # -1 means "use kernel default".
+    traffic_class = -1
+
+    def ancillaryMapping(self, ancdata):
+        # Given ancillary data list ancdata, return a mapping from
+        # pairs (cmsg_level, cmsg_type) to corresponding cmsg_data.
+        # Check that no (level, type) pair appears more than once.
+        d = {}
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertNotIn((cmsg_level, cmsg_type), d)
+            d[(cmsg_level, cmsg_type)] = cmsg_data
+        return d
+
+    def checkHopLimit(self, ancbufsize, maxhop=255, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space.  Check that data is MSG, ancillary data is not
+        # truncated (but ignore any flags in ignoreflags), and hop
+        # limit is between 0 and maxhop inclusive.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        self.assertIsInstance(ancdata[0], tuple)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+        self.assertIsInstance(cmsg_data, bytes)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimit(self):
+        # Test receiving the packet hop limit as ancillary data.
+        self.checkHopLimit(ancbufsize=10240)
+
+    @testRecvHopLimit.client_skip
+    def _testRecvHopLimit(self):
+        # Need to wait until server has asked to receive ancillary
+        # data, as implementations are not required to buffer it
+        # otherwise.
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimitCMSG_SPACE(self):
+        # Test receiving hop limit, using CMSG_SPACE to calculate buffer size.
+        self.checkHopLimit(ancbufsize=socket.CMSG_SPACE(SIZEOF_INT))
+
+    @testRecvHopLimitCMSG_SPACE.client_skip
+    def _testRecvHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Could test receiving into buffer sized using CMSG_LEN, but RFC
+    # 3542 says portable applications must provide space for trailing
+    # padding.  Implementations may set MSG_CTRUNC if there isn't
+    # enough space for the padding.
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSetHopLimit(self):
+        # Test setting hop limit on outgoing packet and receiving it
+        # at the other end.
+        self.checkHopLimit(ancbufsize=10240, maxhop=self.hop_limit)
+
+    @testSetHopLimit.client_skip
+    def _testSetHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    def checkTrafficClassAndHopLimit(self, ancbufsize, maxhop=255,
+                                     ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space.  Check that data is MSG, ancillary
+        # data is not truncated (but ignore any flags in ignoreflags),
+        # and traffic class and hop limit are in range (hop limit no
+        # more than maxhop).
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+        self.assertEqual(len(ancdata), 2)
+        ancmap = self.ancillaryMapping(ancdata)
+
+        tcdata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_TCLASS)]
+        self.assertEqual(len(tcdata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(tcdata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        hldata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT)]
+        self.assertEqual(len(hldata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(hldata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimit(self):
+        # Test receiving traffic class and hop limit as ancillary data.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240)
+
+    @testRecvTrafficClassAndHopLimit.client_skip
+    def _testRecvTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        # Test receiving traffic class and hop limit, using
+        # CMSG_SPACE() to calculate buffer size.
+        self.checkTrafficClassAndHopLimit(
+            ancbufsize=socket.CMSG_SPACE(SIZEOF_INT) * 2)
+
+    @testRecvTrafficClassAndHopLimitCMSG_SPACE.client_skip
+    def _testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSetTrafficClassAndHopLimit(self):
+        # Test setting traffic class and hop limit on outgoing packet,
+        # and receiving them at the other end.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testSetTrafficClassAndHopLimit.client_skip
+    def _testSetTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                                   array.array("i", [self.traffic_class])),
+                                  (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testOddCmsgSize(self):
+        # Try to send ancillary data with first item one byte too
+        # long.  Fall back to sending with correct size if this fails,
+        # and check that second item was handled correctly.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testOddCmsgSize.client_skip
+    def _testOddCmsgSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        try:
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class]).tostring() + b"\x00"),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+        except socket.error as e:
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class])),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+            self.assertEqual(nbytes, len(MSG))
+
+    # Tests for proper handling of truncated ancillary data
+
+    def checkHopLimitTruncatedHeader(self, ancbufsize, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space, which should be too small to contain the ancillary
+        # data header (if ancbufsize is None, pass no second argument
+        # to recvmsg()).  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and no ancillary data is
+        # returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        args = () if ancbufsize is None else (ancbufsize,)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), *args)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no ancillary
+        # buffer size is provided.
+        self.checkHopLimitTruncatedHeader(ancbufsize=None,
+                                          # BSD seems to set
+                                          # MSG_CTRUNC only if an item
+                                          # has been partially
+                                          # received.
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testCmsgTruncNoBufSize.client_skip
+    def _testCmsgTruncNoBufSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc0(self):
+        # Check that no ancillary data is received when ancillary
+        # buffer size is zero.
+        self.checkHopLimitTruncatedHeader(ancbufsize=0,
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testSingleCmsgTrunc0.client_skip
+    def _testSingleCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=1)
+
+    @testSingleCmsgTrunc1.client_skip
+    def _testSingleCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc2Int(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=2 * SIZEOF_INT)
+
+    @testSingleCmsgTrunc2Int.client_skip
+    def _testSingleCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncLen0Minus1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=socket.CMSG_LEN(0) - 1)
+
+    @testSingleCmsgTruncLen0Minus1.client_skip
+    def _testSingleCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncInData(self):
+        # Test truncation of a control message inside its associated
+        # data.  The message may be returned with its data truncated,
+        # or not returned at all.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG), socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        self.assertLessEqual(len(ancdata), 1)
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    @testSingleCmsgTruncInData.client_skip
+    def _testSingleCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    def checkTruncatedSecondHeader(self, ancbufsize, ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space, which should be large enough to
+        # contain the first item, but too small to contain the header
+        # of the second.  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and only one ancillary
+        # data item is returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertIn(cmsg_type, {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT})
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+    # Try the above test with various buffer sizes.
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc0(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT),
+                                        ignoreflags=socket.MSG_CTRUNC)
+
+    @testSecondCmsgTrunc0.client_skip
+    def _testSecondCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) + 1)
+
+    @testSecondCmsgTrunc1.client_skip
+    def _testSecondCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc2Int(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        2 * SIZEOF_INT)
+
+    @testSecondCmsgTrunc2Int.client_skip
+    def _testSecondCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTruncLen0Minus1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        socket.CMSG_LEN(0) - 1)
+
+    @testSecondCmsgTruncLen0Minus1.client_skip
+    def _testSecondCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecomdCmsgTruncInData(self):
+        # Test truncation of the second of two control messages inside
+        # its associated data.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG),
+            socket.CMSG_SPACE(SIZEOF_INT) + socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        cmsg_types = {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT}
+
+        cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        cmsg_types.remove(cmsg_type)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            cmsg_types.remove(cmsg_type)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+        self.assertEqual(ancdata, [])
+
+    @testSecomdCmsgTruncInData.client_skip
+    def _testSecomdCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+
+# Derive concrete test classes for different socket types.
+
+class SendrecvmsgUDPTestBase(SendrecvmsgDgramFlagsBase,
+                             SendrecvmsgConnectionlessBase,
+                             ThreadedSocketTestMixin, UDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
 @unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDPTest(SendmsgConnectionlessTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDPTest(RecvmsgTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDPTest(RecvmsgIntoTests, SendrecvmsgUDPTestBase):
+    pass
+
+
+class SendrecvmsgUDP6TestBase(SendrecvmsgDgramFlagsBase,
+                              SendrecvmsgConnectionlessBase,
+                              ThreadedSocketTestMixin, UDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDP6Test(SendmsgConnectionlessTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDP6Test(RecvmsgTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDP6Test(RecvmsgIntoTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgRFC3542AncillaryUDP6Test(RFC3542AncillaryTest,
+                                      SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoRFC3542AncillaryUDP6Test(RecvmsgIntoMixin,
+                                          RFC3542AncillaryTest,
+                                          SendrecvmsgUDP6TestBase):
+    pass
+
+
+class SendrecvmsgTCPTestBase(SendrecvmsgConnectedBase,
+                             ConnectedStreamTestMixin, TCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgTCPTest(SendmsgStreamTests, SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgTCPTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                     SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoTCPTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                         SendrecvmsgTCPTestBase):
+    pass
+
+
+class SendrecvmsgSCTPStreamTestBase(SendrecvmsgSCTPFlagsBase,
+                                    SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, SCTPStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgSCTPStreamTest(SendmsgStreamTests, SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCTPStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCTPStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgSCTPStreamTestBase):
+    pass
+
+
+class SendrecvmsgUnixStreamTestBase(SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, UnixStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUnixStreamTest(SendmsgStreamTests, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUnixStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUnixStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCMRightsStreamTest(SCMRightsTest, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCMRightsStreamTest(RecvmsgIntoMixin, SCMRightsTest,
+                                     SendrecvmsgUnixStreamTestBase):
+    pass
+
+
+# Test interrupting the interruptible send/receive methods with a
+# signal when a timeout is set.  These tests avoid having multiple
+# threads alive during the test so that the OS cannot deliver the
+# signal to the wrong one.
+
+class InterruptedTimeoutBase(unittest.TestCase):
+    # Base class for interrupted send/receive tests.  Installs an
+    # empty handler for SIGALRM and removes it on teardown, along with
+    # any scheduled alarms.
+
+    def setUp(self):
+        super().setUp()
+        orig_alrm_handler = signal.signal(signal.SIGALRM,
+                                          lambda signum, frame: None)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+        self.addCleanup(self.setAlarm, 0)
+
+    # Timeout for socket operations
+    timeout = 4.0
+
+    # Provide setAlarm() method to schedule delivery of SIGALRM after
+    # given number of seconds, or cancel it if zero, and an
+    # appropriate time value to use.  Use setitimer() if available.
+    if hasattr(signal, "setitimer"):
+        alarm_time = 0.05
+
+        def setAlarm(self, seconds):
+            signal.setitimer(signal.ITIMER_REAL, seconds)
+    else:
+        # Old systems may deliver the alarm up to one second early
+        alarm_time = 2
+
+        def setAlarm(self, seconds):
+            signal.alarm(seconds)
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+class InterruptedRecvTimeoutTest(InterruptedTimeoutBase, UDPTestBase):
+    # Test interrupting the recv*() methods with signals when a
+    # timeout is set.
+
+    def setUp(self):
+        super().setUp()
+        self.serv.settimeout(self.timeout)
+
+    def checkInterruptedRecv(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs) raises socket.error with an
+        # errno of EINTR when interrupted by a signal.
+        self.setAlarm(self.alarm_time)
+        with self.assertRaises(socket.error) as cm:
+            func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedRecvTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv, 1024)
+
+    def testInterruptedRecvIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv_into, bytearray(1024))
+
+    def testInterruptedRecvfromTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom, 1024)
+
+    def testInterruptedRecvfromIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom_into, bytearray(1024))
+
+    @requireAttrs(socket.socket, "recvmsg")
+    def testInterruptedRecvmsgTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg, 1024)
+
+    @requireAttrs(socket.socket, "recvmsg_into")
+    def testInterruptedRecvmsgIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg_into, [bytearray(1024)])
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class InterruptedSendTimeoutTest(InterruptedTimeoutBase,
+                                 ThreadSafeCleanupTestCase,
+                                 SocketListeningTestMixin, TCPTestBase):
+    # Test interrupting the interruptible send*() methods with signals
+    # when a timeout is set.
+
+    def setUp(self):
+        super().setUp()
+        self.serv_conn = self.newSocket()
+        self.addCleanup(self.serv_conn.close)
+        # Use a thread to complete the connection, but wait for it to
+        # terminate before running the test, so that there is only one
+        # thread to accept the signal.
+        cli_thread = threading.Thread(target=self.doConnect)
+        cli_thread.start()
+        self.cli_conn, addr = self.serv.accept()
+        self.addCleanup(self.cli_conn.close)
+        cli_thread.join()
+        self.serv_conn.settimeout(self.timeout)
+
+    def doConnect(self):
+        self.serv_conn.connect(self.serv_addr)
+
+    def checkInterruptedSend(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs), run in a loop, raises
+        # socket.error with an errno of EINTR when interrupted by a
+        # signal.
+        with self.assertRaises(socket.error) as cm:
+            while True:
+                self.setAlarm(self.alarm_time)
+                func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedSendTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.send, b"a"*512)
+
+    def testInterruptedSendtoTimeout(self):
+        # Passing an actual address here as Python's wrapper for
+        # sendto() doesn't allow passing a zero-length one; POSIX
+        # requires that the address is ignored since the socket is
+        # connection-mode, however.
+        self.checkInterruptedSend(self.serv_conn.sendto, b"a"*512,
+                                  self.serv_addr)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testInterruptedSendmsgTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.sendmsg, [b"a"*512])
+
+
+ at unittest.skipUnless(thread, 'Threading required for this test.')
 class TCPCloserTest(ThreadedTCPSocketTest):
 
     def testClose(self):
@@ -1974,6 +4069,31 @@
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)
+    tests.extend([
+        CmsgMacroTests,
+        SendmsgUDPTest,
+        RecvmsgUDPTest,
+        RecvmsgIntoUDPTest,
+        SendmsgUDP6Test,
+        RecvmsgUDP6Test,
+        RecvmsgRFC3542AncillaryUDP6Test,
+        RecvmsgIntoRFC3542AncillaryUDP6Test,
+        RecvmsgIntoUDP6Test,
+        SendmsgTCPTest,
+        RecvmsgTCPTest,
+        RecvmsgIntoTCPTest,
+        SendmsgSCTPStreamTest,
+        RecvmsgSCTPStreamTest,
+        RecvmsgIntoSCTPStreamTest,
+        SendmsgUnixStreamTest,
+        RecvmsgUnixStreamTest,
+        RecvmsgIntoUnixStreamTest,
+        RecvmsgSCMRightsStreamTest,
+        RecvmsgIntoSCMRightsStreamTest,
+        # These are slow when setitimer() is not available
+        InterruptedRecvTimeoutTest,
+        InterruptedSendTimeoutTest,
+    ])
 
     thread_info = support.threading_setup()
     support.run_unittest(*tests)
Index: Modules/socketmodule.c
===================================================================
--- Modules/socketmodule.c	(revision 87092)
+++ Modules/socketmodule.c	(working copy)
@@ -249,6 +249,7 @@
 #ifdef HAVE_SYS_TYPES_H
 #include <sys/types.h>
 #endif
+#include <unistd.h>
 
 /* Generic socket object definitions and includes */
 #define PySocket_BUILDING_SOCKET
@@ -455,6 +456,17 @@
 #include <sys/poll.h>
 #endif
 
+/* Largest value to try to store in a socklen_t (used when handling
+   ancillary data).  POSIX requires socklen_t to hold at least
+   (2**31)-1 and recommends against storing larger values, but
+   socklen_t was originally int in the BSD interface, so to be on the
+   safe side we use the smaller of (2**31)-1 and INT_MAX. */
+#if INT_MAX > 0x7fffffff
+#define SOCKLEN_T_LIMIT 0x7fffffff
+#else
+#define SOCKLEN_T_LIMIT INT_MAX
+#endif
+
 #ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
 /* Platform can select file descriptors beyond FD_SETSIZE */
 #define IS_SELECTABLE(s) 1
@@ -1664,6 +1676,117 @@
 }
 
 
+/* Support functions for the sendmsg() and recvmsg[_into]() methods.
+   Currently, these methods are only compiled if the RFC 2292/3542
+   CMSG_LEN() macro is available.  Older systems seem to have used
+   sizeof(struct cmsghdr) + (length) where CMSG_LEN() is used now, so
+   it may be possible to define CMSG_LEN() that way if it's not
+   provided.  Some architectures might need extra padding after the
+   cmsghdr, however, and CMSG_LEN() would have to take account of
+   this. */
+#ifdef CMSG_LEN
+/* If length is in range, set *result to CMSG_LEN(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_LEN(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    if (length > (SOCKLEN_T_LIMIT - CMSG_LEN(0)))
+        return 0;
+    tmp = CMSG_LEN(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+
+#ifdef CMSG_SPACE
+/* If length is in range, set *result to CMSG_SPACE(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_SPACE(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    /* Use CMSG_SPACE(1) here in order to take account of the padding
+       necessary before *and* after the data. */
+    if (length > (SOCKLEN_T_LIMIT - CMSG_SPACE(1)))
+        return 0;
+    tmp = CMSG_SPACE(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+#endif
+
+/* Return true iff msg->msg_controllen is valid, cmsgh is a valid
+   pointer in msg->msg_control with at least "space" bytes after it,
+   and its cmsg_len member inside the buffer. */
+static int
+cmsg_min_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t space)
+{
+    size_t cmsg_offset;
+    static const size_t cmsg_len_end = (offsetof(struct cmsghdr, cmsg_len) +
+                                        sizeof(cmsgh->cmsg_len));
+
+    if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0)
+        return 0;
+    if (space < cmsg_len_end)
+        space = cmsg_len_end;
+    cmsg_offset = (char *)cmsgh - (char *)msg->msg_control;
+    return (cmsg_offset <= (size_t)-1 - space &&
+            cmsg_offset + space <= msg->msg_controllen);
+}
+
+/* If pointer CMSG_DATA(cmsgh) is in buffer msg->msg_control, set
+   *space to number of bytes following it in the buffer and return
+   true; otherwise, return false.  Assumes cmsgh, msg->msg_control and
+   msg->msg_controllen are valid. */
+static int
+get_cmsg_data_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *space)
+{
+    size_t data_offset;
+    char *data_ptr;
+
+    if ((data_ptr = (char *)CMSG_DATA(cmsgh)) == NULL)
+        return 0;
+    data_offset = data_ptr - (char *)msg->msg_control;
+    if (data_offset > msg->msg_controllen)
+        return 0;
+    *space = msg->msg_controllen - data_offset;
+    return 1;
+}
+
+/* If cmsgh is invalid or not contained in the buffer pointed to by
+   msg->msg_control, return -1.  If cmsgh is valid and its associated
+   data is entirely contained in the buffer, set *data_len to the
+   length of the associated data and return 0.  If only part of the
+   associated data is contained in the buffer but cmsgh is otherwise
+   valid, set *data_len to the length contained in the buffer and
+   return 1. */
+static int
+get_cmsg_data_len(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *data_len)
+{
+    size_t space, cmsg_data_len;
+
+    if (!cmsg_min_space(msg, cmsgh, CMSG_LEN(0)) ||
+        cmsgh->cmsg_len < CMSG_LEN(0))
+        return -1;
+    cmsg_data_len = cmsgh->cmsg_len - CMSG_LEN(0);
+    if (!get_cmsg_data_space(msg, cmsgh, &space))
+        return -1;
+    if (space >= cmsg_data_len) {
+        *data_len = cmsg_data_len;
+        return 0;
+    }
+    *data_len = space;
+    return 1;
+}
+#endif    /* CMSG_LEN */
+
+
 /* s._accept() -> (fd, address) */
 
 static PyObject *
@@ -2614,6 +2737,333 @@
 Like recv_into(buffer[, nbytes[, flags]]) but also return the sender's address info.");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/*
+ * Call recvmsg() with the supplied iovec structures, flags, and
+ * ancillary data buffer size (controllen).  Returns the tuple return
+ * value for recvmsg() or recvmsg_into(), with the first item provided
+ * by the supplied makeval() function.  makeval() will be called with
+ * the length read and makeval_data as arguments, and must return a
+ * new reference (which will be decrefed if there is a subsequent
+ * error).  On error, closes any file descriptors received via
+ * SCM_RIGHTS.
+ */
+static PyObject *
+sock_recvmsg_guts(PySocketSockObject *s, struct iovec *iov, int iovlen,
+                  int flags, Py_ssize_t controllen,
+                  PyObject *(*makeval)(ssize_t, void *), void *makeval_data)
+{
+    ssize_t bytes_received = -1;
+    int timeout;
+    sock_addr_t addrbuf;
+    socklen_t addrbuflen;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    PyObject *cmsg_list = NULL, *retval = NULL;
+    void *controlbuf = NULL;
+    struct cmsghdr *cmsgh;
+    size_t cmsgdatalen = 0;
+    int cmsg_status;
+
+    /* XXX: POSIX says that msg_name and msg_namelen "shall be
+       ignored" when the socket is connected (Linux fills them in
+       anyway for AF_UNIX sockets at least).  Normally msg_namelen
+       seems to be set to 0 if there's no address, but try to
+       initialize msg_name to something that won't be mistaken for a
+       real address if that doesn't happen. */
+    if (!getsockaddrlen(s, &addrbuflen))
+        return NULL;
+    memset(&addrbuf, 0, addrbuflen);
+    SAS2SA(&addrbuf)->sa_family = AF_UNSPEC;
+
+    if (controllen < 0 || controllen > SOCKLEN_T_LIMIT) {
+        PyErr_SetString(PyExc_ValueError,
+                        "invalid ancillary data buffer length");
+        return NULL;
+    }
+    if (controllen > 0 && (controlbuf = PyMem_Malloc(controllen)) == NULL)
+        return PyErr_NoMemory();
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    BEGIN_SELECT_LOOP(s)
+    Py_BEGIN_ALLOW_THREADS;
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+    msg.msg_name = SAS2SA(&addrbuf);
+    msg.msg_namelen = addrbuflen;
+    msg.msg_iov = iov;
+    msg.msg_iovlen = iovlen;
+    msg.msg_control = controlbuf;
+    msg.msg_controllen = controllen;
+    timeout = internal_select_ex(s, 0, interval);
+    if (!timeout)
+        bytes_received = recvmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+    END_SELECT_LOOP(s)
+
+    if (bytes_received < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+
+    /* Make list of (level, type, data) tuples from control messages. */
+    if ((cmsg_list = PyList_New(0)) == NULL)
+        goto err_closefds;
+    /* Check for empty ancillary data as old CMSG_FIRSTHDR()
+       implementations didn't do so. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        PyObject *bytes, *tuple;
+        int tmp;
+
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status != 0) {
+            if (PyErr_WarnEx(PyExc_RuntimeWarning,
+                             "received malformed or improperly-truncated "
+                             "ancillary data", 1) == -1)
+                goto err_closefds;
+        }
+        if (cmsg_status < 0)
+            break;
+        if (cmsgdatalen > PY_SSIZE_T_MAX) {
+            PyErr_SetString(socket_error, "control message too long");
+            goto err_closefds;
+        }
+
+        bytes = PyBytes_FromStringAndSize((char *)CMSG_DATA(cmsgh),
+                                          cmsgdatalen);
+        tuple = Py_BuildValue("iiN", (int)cmsgh->cmsg_level,
+                              (int)cmsgh->cmsg_type, bytes);
+        if (tuple == NULL)
+            goto err_closefds;
+        tmp = PyList_Append(cmsg_list, tuple);
+        Py_DECREF(tuple);
+        if (tmp != 0)
+            goto err_closefds;
+
+        if (cmsg_status != 0)
+            break;
+    }
+
+    retval = Py_BuildValue("NOiN",
+                           (*makeval)(bytes_received, makeval_data),
+                           cmsg_list,
+                           (int)msg.msg_flags,
+                           makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                                        ((msg.msg_namelen > addrbuflen) ?
+                                         addrbuflen : msg.msg_namelen),
+                                        s->sock_proto));
+    if (retval == NULL)
+        goto err_closefds;
+
+finally:
+    Py_XDECREF(cmsg_list);
+    PyMem_Free(controlbuf);
+    return retval;
+
+err_closefds:
+#ifdef SCM_RIGHTS
+    /* Close all descriptors coming from SCM_RIGHTS, so they don't leak. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status < 0)
+            break;
+        if (cmsgh->cmsg_level == SOL_SOCKET &&
+            cmsgh->cmsg_type == SCM_RIGHTS) {
+            size_t numfds;
+            int *fdp;
+
+            numfds = cmsgdatalen / sizeof(int);
+            fdp = (int *)CMSG_DATA(cmsgh);
+            while (numfds-- > 0)
+                close(*fdp++);
+        }
+        if (cmsg_status != 0)
+            break;
+    }
+#endif /* SCM_RIGHTS */
+    goto finally;
+}
+
+
+static PyObject *
+makeval_recvmsg(ssize_t received, void *data)
+{
+    PyObject **buf = data;
+
+    if (received < PyBytes_GET_SIZE(*buf))
+        _PyBytes_Resize(buf, received);
+    Py_XINCREF(*buf);
+    return *buf;
+}
+
+/* s.recvmsg(bufsize[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t bufsize, ancbufsize = 0;
+    int flags = 0;
+    struct iovec iov;
+    PyObject *buf = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "n|ni:recvmsg", &bufsize, &ancbufsize, &flags))
+        return NULL;
+
+    if (bufsize < 0) {
+        PyErr_SetString(PyExc_ValueError, "negative buffer size in recvmsg()");
+        return NULL;
+    }
+    if ((buf = PyBytes_FromStringAndSize(NULL, bufsize)) == NULL)
+        return NULL;
+    iov.iov_base = PyBytes_AS_STRING(buf);
+    iov.iov_len = bufsize;
+
+    /* Note that we're passing a pointer to *our pointer* to the bytes
+       object here (&buf); makeval_recvmsg() may incref the object, or
+       deallocate it and set our pointer to NULL. */
+    retval = sock_recvmsg_guts(s, &iov, 1, flags, ancbufsize,
+                               &makeval_recvmsg, &buf);
+    Py_XDECREF(buf);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_doc,
+"recvmsg(bufsize[, ancbufsize[, flags]]) -> (data, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data (up to bufsize bytes) and ancillary data from the\n\
+socket.  The ancbufsize argument sets the size in bytes of the\n\
+internal buffer used to receive the ancillary data; it defaults to 0,\n\
+meaning that no ancillary data will be received.  Appropriate buffer\n\
+sizes for ancillary data can be calculated using CMSG_SPACE() or\n\
+CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (data, ancdata, msg_flags, address).\n\
+The data item is a bytes object holding the non-ancillary data\n\
+received.  The ancdata item is a list of zero or more tuples\n\
+(cmsg_level, cmsg_type, cmsg_data) representing the ancillary data\n\
+(control messages) received: cmsg_level and cmsg_type are integers\n\
+specifying the protocol level and protocol-specific type respectively,\n\
+and cmsg_data is a bytes object holding the associated data.  The\n\
+msg_flags item is the bitwise OR of various flags indicating\n\
+conditions on the received message; see your system documentation for\n\
+details.  If the receiving socket is unconnected, address is the\n\
+address of the sending socket, if available; otherwise, its value is\n\
+unspecified.\n\
+\n\
+If recvmsg() raises an exception after the system call returns, it\n\
+will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+
+
+static PyObject *
+makeval_recvmsg_into(ssize_t received, void *data)
+{
+    return PyLong_FromSsize_t(received);
+}
+
+/* s.recvmsg_into(buffers[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg_into(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t ancbufsize = 0;
+    int flags = 0;
+    struct iovec *iovs = NULL;
+    Py_ssize_t i, nitems, nbufs = 0;
+    Py_buffer *bufs = NULL;
+    PyObject *buffers_arg, *fast, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|ni:recvmsg_into",
+                          &buffers_arg, &ancbufsize, &flags))
+        return NULL;
+
+    if ((fast = PySequence_Fast(buffers_arg,
+                                "recvmsg_into() argument 1 must be an "
+                                "iterable")) == NULL)
+        return NULL;
+    nitems = PySequence_Fast_GET_SIZE(fast);
+    if (nitems > INT_MAX) {
+        PyErr_SetString(socket_error, "recvmsg_into() argument 1 is too long");
+        goto finally;
+    }
+
+    /* Fill in an iovec for each item, and save the Py_buffer
+       structs to release afterwards. */
+    if (nitems > 0 && ((iovs = PyMem_New(struct iovec, nitems)) == NULL ||
+                       (bufs = PyMem_New(Py_buffer, nitems)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; nbufs < nitems; nbufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(fast, nbufs),
+                         "w*;recvmsg_into() argument 1 must be an iterable "
+                         "of single-segment read-write buffers",
+                         &bufs[nbufs]))
+            goto finally;
+        iovs[nbufs].iov_base = bufs[nbufs].buf;
+        iovs[nbufs].iov_len = bufs[nbufs].len;
+    }
+
+    retval = sock_recvmsg_guts(s, iovs, nitems, flags, ancbufsize,
+                               &makeval_recvmsg_into, NULL);
+finally:
+    for (i = 0; i < nbufs; i++)
+        PyBuffer_Release(&bufs[i]);
+    PyMem_Free(bufs);
+    PyMem_Free(iovs);
+    Py_DECREF(fast);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_into_doc,
+"recvmsg_into(buffers[, ancbufsize[, flags]]) -> (nbytes, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data and ancillary data from the socket, scattering the\n\
+non-ancillary data into a series of buffers.  The buffers argument\n\
+must be an iterable of objects that export writable buffers\n\
+(e.g. bytearray objects); these will be filled with successive chunks\n\
+of the non-ancillary data until it has all been written or there are\n\
+no more buffers.  The ancbufsize argument sets the size in bytes of\n\
+the internal buffer used to receive the ancillary data; it defaults to\n\
+0, meaning that no ancillary data will be received.  Appropriate\n\
+buffer sizes for ancillary data can be calculated using CMSG_SPACE()\n\
+or CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (nbytes, ancdata, msg_flags, address).\n\
+The nbytes item is the total number of bytes of non-ancillary data\n\
+written into the buffers.  The ancdata item is a list of zero or more\n\
+tuples (cmsg_level, cmsg_type, cmsg_data) representing the ancillary\n\
+data (control messages) received: cmsg_level and cmsg_type are\n\
+integers specifying the protocol level and protocol-specific type\n\
+respectively, and cmsg_data is a bytes object holding the associated\n\
+data.  The msg_flags item is the bitwise OR of various flags\n\
+indicating conditions on the received message; see your system\n\
+documentation for details.  If the receiving socket is unconnected,\n\
+address is the address of the sending socket, if available; otherwise,\n\
+its value is unspecified.\n\
+\n\
+If recvmsg_into() raises an exception after the system call returns,\n\
+it will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+#endif    /* CMSG_LEN */
+
+
 /* s.send(data [,flags]) method */
 
 static PyObject *
@@ -2797,6 +3247,237 @@
 For IP sockets, the address is a pair (hostaddr, port).");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/* s.sendmsg(buffers[, ancdata[, flags[, address]]]) method */
+
+static PyObject *
+sock_sendmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t i, ndataparts, ndatabufs = 0, ncmsgs, ncmsgbufs = 0;
+    Py_buffer *databufs = NULL;
+    struct iovec *iovs = NULL;
+    sock_addr_t addrbuf;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    struct cmsginfo {
+        int level;
+        int type;
+        Py_buffer data;
+    } *cmsgs = NULL;
+    void *controlbuf = NULL;
+    size_t controllen, controllen_last;
+    ssize_t bytes_sent = -1;
+    int addrlen, timeout, flags = 0;
+    PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL,
+        *cmsg_fast = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|OiO:sendmsg",
+                          &data_arg, &cmsg_arg, &flags, &addr_arg))
+        return NULL;
+
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+
+    /* Parse destination address. */
+    if (addr_arg != NULL && addr_arg != Py_None) {
+        if (!getsockaddrarg(s, addr_arg, SAS2SA(&addrbuf), &addrlen))
+            goto finally;
+        msg.msg_name = &addrbuf;
+        msg.msg_namelen = addrlen;
+    }
+
+    /* Fill in an iovec for each message part, and save the Py_buffer
+       structs to release afterwards. */
+    if ((data_fast = PySequence_Fast(data_arg,
+                                     "sendmsg() argument 1 must be an "
+                                     "iterable")) == NULL)
+        goto finally;
+    ndataparts = PySequence_Fast_GET_SIZE(data_fast);
+    if (ndataparts > INT_MAX) {
+        PyErr_SetString(socket_error, "sendmsg() argument 1 is too long");
+        goto finally;
+    }
+    msg.msg_iovlen = ndataparts;
+    if (ndataparts > 0 &&
+        ((msg.msg_iov = iovs = PyMem_New(struct iovec, ndataparts)) == NULL ||
+         (databufs = PyMem_New(Py_buffer, ndataparts)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; ndatabufs < ndataparts; ndatabufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(data_fast, ndatabufs),
+                         "y*;sendmsg() argument 1 must be an iterable of "
+                         "buffer-compatible objects",
+                         &databufs[ndatabufs]))
+            goto finally;
+        iovs[ndatabufs].iov_base = databufs[ndatabufs].buf;
+        iovs[ndatabufs].iov_len = databufs[ndatabufs].len;
+    }
+
+    if (cmsg_arg == NULL)
+        ncmsgs = 0;
+    else {
+        if ((cmsg_fast = PySequence_Fast(cmsg_arg,
+                                         "sendmsg() argument 2 must be an "
+                                         "iterable")) == NULL)
+            goto finally;
+        ncmsgs = PySequence_Fast_GET_SIZE(cmsg_fast);
+    }
+
+#ifndef CMSG_SPACE
+    if (ncmsgs > 1) {
+        PyErr_SetString(socket_error,
+                        "sending multiple control messages is not supported "
+                        "on this system");
+        goto finally;
+    }
+#endif
+    /* Save level, type and Py_buffer for each control message,
+       and calculate total size. */
+    if (ncmsgs > 0 && (cmsgs = PyMem_New(struct cmsginfo, ncmsgs)) == NULL) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    controllen = controllen_last = 0;
+    while (ncmsgbufs < ncmsgs) {
+        size_t bufsize, space;
+
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(cmsg_fast, ncmsgbufs),
+                         "(iiy*):[sendmsg() ancillary data items]",
+                         &cmsgs[ncmsgbufs].level,
+                         &cmsgs[ncmsgbufs].type,
+                         &cmsgs[ncmsgbufs].data))
+            goto finally;
+        bufsize = cmsgs[ncmsgbufs++].data.len;
+
+#ifdef CMSG_SPACE
+        if (!get_CMSG_SPACE(bufsize, &space)) {
+#else
+        if (!get_CMSG_LEN(bufsize, &space)) {
+#endif
+            PyErr_SetString(socket_error, "ancillary data item too large");
+            goto finally;
+        }
+        controllen += space;
+        if (controllen > SOCKLEN_T_LIMIT || controllen < controllen_last) {
+            PyErr_SetString(socket_error, "too much ancillary data");
+            goto finally;
+        }
+        controllen_last = controllen;
+    }
+
+    /* Construct ancillary data block from control message info. */
+    if (ncmsgbufs > 0) {
+        struct cmsghdr *cmsgh = NULL;
+
+        if ((msg.msg_control = controlbuf =
+             PyMem_Malloc(controllen)) == NULL) {
+            PyErr_NoMemory();
+            goto finally;
+        }
+        msg.msg_controllen = controllen;
+
+        /* Need to zero out the buffer as a workaround for glibc's
+           CMSG_NXTHDR() implementation.  After getting the pointer to
+           the next header, it checks its (uninitialized) cmsg_len
+           member to see if the "message" fits in the buffer, and
+           returns NULL if it doesn't.  Zero-filling the buffer
+           ensures that that doesn't happen. */
+        memset(controlbuf, 0, controllen);
+
+        for (i = 0; i < ncmsgbufs; i++) {
+            size_t msg_len, data_len = cmsgs[i].data.len;
+            int enough_space = 0;
+
+            cmsgh = (i == 0) ? CMSG_FIRSTHDR(&msg) : CMSG_NXTHDR(&msg, cmsgh);
+            if (cmsgh == NULL) {
+                PyErr_Format(PyExc_RuntimeError,
+                             "unexpected NULL result from %s()",
+                             (i == 0) ? "CMSG_FIRSTHDR" : "CMSG_NXTHDR");
+                goto finally;
+            }
+            if (!get_CMSG_LEN(data_len, &msg_len)) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "item size out of range for CMSG_LEN()");
+                goto finally;
+            }
+            if (cmsg_min_space(&msg, cmsgh, msg_len)) {
+                size_t space;
+
+                cmsgh->cmsg_len = msg_len;
+                if (get_cmsg_data_space(&msg, cmsgh, &space))
+                    enough_space = (space >= data_len);
+            }
+            if (!enough_space) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "ancillary data does not fit in calculated "
+                                "space");
+                goto finally;
+            }
+            cmsgh->cmsg_level = cmsgs[i].level;
+            cmsgh->cmsg_type = cmsgs[i].type;
+            memcpy(CMSG_DATA(cmsgh), cmsgs[i].data.buf, data_len);
+        }
+    }
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    BEGIN_SELECT_LOOP(s)
+    Py_BEGIN_ALLOW_THREADS;
+    timeout = internal_select_ex(s, 1, interval);
+    if (!timeout)
+        bytes_sent = sendmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+    END_SELECT_LOOP(s)
+
+    if (bytes_sent < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+    retval = PyLong_FromSsize_t(bytes_sent);
+
+finally:
+    PyMem_Free(controlbuf);
+    for (i = 0; i < ncmsgbufs; i++)
+        PyBuffer_Release(&cmsgs[i].data);
+    PyMem_Free(cmsgs);
+    Py_XDECREF(cmsg_fast);
+    for (i = 0; i < ndatabufs; i++)
+        PyBuffer_Release(&databufs[i]);
+    PyMem_Free(databufs);
+    PyMem_Free(iovs);
+    Py_XDECREF(data_fast);
+    return retval;
+}
+
+PyDoc_STRVAR(sendmsg_doc,
+"sendmsg(buffers[, ancdata[, flags[, address]]]) -> count\n\
+\n\
+Send normal and ancillary data to the socket, gathering the\n\
+non-ancillary data from a series of buffers and concatenating it into\n\
+a single message.  The buffers argument specifies the non-ancillary\n\
+data as an iterable of buffer-compatible objects (e.g. bytes objects).\n\
+The ancdata argument specifies the ancillary data (control messages)\n\
+as an iterable of zero or more tuples (cmsg_level, cmsg_type,\n\
+cmsg_data), where cmsg_level and cmsg_type are integers specifying the\n\
+protocol level and protocol-specific type respectively, and cmsg_data\n\
+is a buffer-compatible object holding the associated data.  The flags\n\
+argument defaults to 0 and has the same meaning as for send().  If\n\
+address is supplied and not None, it sets a destination address for\n\
+the message.  The return value is the number of bytes of non-ancillary\n\
+data sent.");
+#endif    /* CMSG_LEN */
+
+
 /* s.shutdown(how) method */
 
 static PyObject *
@@ -2923,6 +3604,14 @@
                       setsockopt_doc},
     {"shutdown",          (PyCFunction)sock_shutdown, METH_O,
                       shutdown_doc},
+#ifdef CMSG_LEN
+    {"recvmsg",           (PyCFunction)sock_recvmsg, METH_VARARGS,
+                      recvmsg_doc},
+    {"recvmsg_into",      (PyCFunction)sock_recvmsg_into, METH_VARARGS,
+                      recvmsg_into_doc,},
+    {"sendmsg",           (PyCFunction)sock_sendmsg, METH_VARARGS,
+                      sendmsg_doc},
+#endif
     {NULL,                      NULL}           /* sentinel */
 };
 
@@ -4220,6 +4909,68 @@
 When the socket module is first imported, the default is None.");
 
 
+#ifdef CMSG_LEN
+/* Python interface to CMSG_LEN(length). */
+
+static PyObject *
+socket_CMSG_LEN(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_LEN", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_LEN(length, &result)) {
+        PyErr_Format(PyExc_OverflowError, "CMSG_LEN() argument out of range");
+        return NULL;
+    }
+    return PyLong_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_LEN_doc,
+"CMSG_LEN(length) -> control message length\n\
+\n\
+Return the total length, without trailing padding, of an ancillary\n\
+data item with associated data of the given length.  This value can\n\
+often be used as the buffer size for recvmsg() to receive a single\n\
+item of ancillary data, but RFC 3542 requires portable applications to\n\
+use CMSG_SPACE() and thus include space for padding, even when the\n\
+item will be the last in the buffer.  Raises OverflowError if length\n\
+is outside the permissible range of values.");
+
+
+#ifdef CMSG_SPACE
+/* Python interface to CMSG_SPACE(length). */
+
+static PyObject *
+socket_CMSG_SPACE(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_SPACE", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_SPACE(length, &result)) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "CMSG_SPACE() argument out of range");
+        return NULL;
+    }
+    return PyLong_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_SPACE_doc,
+"CMSG_SPACE(length) -> buffer size\n\
+\n\
+Return the buffer size needed for recvmsg() to receive an ancillary\n\
+data item with associated data of the given length, along with any\n\
+trailing padding.  The buffer space needed to receive multiple items\n\
+is the sum of the CMSG_SPACE() values for their associated data\n\
+lengths.  Raises OverflowError if length is outside the permissible\n\
+range of values.");
+#endif    /* CMSG_SPACE */
+#endif    /* CMSG_LEN */
+
+
 /* List of functions exported by this module. */
 
 static PyMethodDef socket_methods[] = {
@@ -4271,6 +5022,14 @@
      METH_NOARGS, getdefaulttimeout_doc},
     {"setdefaulttimeout",       socket_setdefaulttimeout,
      METH_O, setdefaulttimeout_doc},
+#ifdef CMSG_LEN
+    {"CMSG_LEN",                socket_CMSG_LEN,
+     METH_VARARGS, CMSG_LEN_doc},
+#ifdef CMSG_SPACE
+    {"CMSG_SPACE",              socket_CMSG_SPACE,
+     METH_VARARGS, CMSG_SPACE_doc},
+#endif
+#endif
     {NULL,                      NULL}            /* Sentinel */
 };
 
@@ -4758,6 +5517,15 @@
 #ifdef  SO_SETFIB
     PyModule_AddIntConstant(m, "SO_SETFIB", SO_SETFIB);
 #endif
+#ifdef  SO_PASSCRED
+    PyModule_AddIntConstant(m, "SO_PASSCRED", SO_PASSCRED);
+#endif
+#ifdef  SO_PEERCRED
+    PyModule_AddIntConstant(m, "SO_PEERCRED", SO_PEERCRED);
+#endif
+#ifdef  LOCAL_PEERCRED
+    PyModule_AddIntConstant(m, "LOCAL_PEERCRED", LOCAL_PEERCRED);
+#endif
 
     /* Maximum number of connections for "listen" */
 #ifdef  SOMAXCONN
@@ -4766,6 +5534,17 @@
     PyModule_AddIntConstant(m, "SOMAXCONN", 5); /* Common value */
 #endif
 
+    /* Ancilliary message types */
+#ifdef  SCM_RIGHTS
+    PyModule_AddIntConstant(m, "SCM_RIGHTS", SCM_RIGHTS);
+#endif
+#ifdef  SCM_CREDENTIALS
+    PyModule_AddIntConstant(m, "SCM_CREDENTIALS", SCM_CREDENTIALS);
+#endif
+#ifdef  SCM_CREDS
+    PyModule_AddIntConstant(m, "SCM_CREDS", SCM_CREDS);
+#endif
+
     /* Flags for send, recv */
 #ifdef  MSG_OOB
     PyModule_AddIntConstant(m, "MSG_OOB", MSG_OOB);
@@ -4797,6 +5576,33 @@
 #ifdef  MSG_ETAG
     PyModule_AddIntConstant(m, "MSG_ETAG", MSG_ETAG);
 #endif
+#ifdef  MSG_NOSIGNAL
+    PyModule_AddIntConstant(m, "MSG_NOSIGNAL", MSG_NOSIGNAL);
+#endif
+#ifdef  MSG_NOTIFICATION
+    PyModule_AddIntConstant(m, "MSG_NOTIFICATION", MSG_NOTIFICATION);
+#endif
+#ifdef  MSG_CMSG_CLOEXEC
+    PyModule_AddIntConstant(m, "MSG_CMSG_CLOEXEC", MSG_CMSG_CLOEXEC);
+#endif
+#ifdef  MSG_ERRQUEUE
+    PyModule_AddIntConstant(m, "MSG_ERRQUEUE", MSG_ERRQUEUE);
+#endif
+#ifdef  MSG_CONFIRM
+    PyModule_AddIntConstant(m, "MSG_CONFIRM", MSG_CONFIRM);
+#endif
+#ifdef  MSG_MORE
+    PyModule_AddIntConstant(m, "MSG_MORE", MSG_MORE);
+#endif
+#ifdef  MSG_EOF
+    PyModule_AddIntConstant(m, "MSG_EOF", MSG_EOF);
+#endif
+#ifdef  MSG_BCAST
+    PyModule_AddIntConstant(m, "MSG_BCAST", MSG_BCAST);
+#endif
+#ifdef  MSG_MCAST
+    PyModule_AddIntConstant(m, "MSG_MCAST", MSG_MCAST);
+#endif
 
     /* Protocol level and numbers, usable for [gs]etsockopt */
 #ifdef  SOL_SOCKET
@@ -4936,6 +5742,9 @@
 #ifdef  IPPROTO_VRRP
     PyModule_AddIntConstant(m, "IPPROTO_VRRP", IPPROTO_VRRP);
 #endif
+#ifdef  IPPROTO_SCTP
+    PyModule_AddIntConstant(m, "IPPROTO_SCTP", IPPROTO_SCTP);
+#endif
 #ifdef  IPPROTO_BIP
     PyModule_AddIntConstant(m, "IPPROTO_BIP", IPPROTO_BIP);
 #endif
-------------- next part --------------
Replace SocketTCPTest, etc. with classes from the sendmsg patch

Index: Lib/test/test_socket.py
===================================================================
--- Lib/test/test_socket.py.orig
+++ Lib/test/test_socket.py
@@ -59,27 +59,6 @@
 # Size in bytes of the int type
 SIZEOF_INT = array.array("i").itemsize
 
-class SocketTCPTest(unittest.TestCase):
-
-    def setUp(self):
-        self.serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.port = support.bind_port(self.serv)
-        self.serv.listen(1)
-
-    def tearDown(self):
-        self.serv.close()
-        self.serv = None
-
-class SocketUDPTest(unittest.TestCase):
-
-    def setUp(self):
-        self.serv = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
-        self.port = support.bind_port(self.serv)
-
-    def tearDown(self):
-        self.serv.close()
-        self.serv = None
-
 class ThreadSafeCleanupTestCase(unittest.TestCase):
     """Subclass of unittest.TestCase with thread-safe cleanup methods.
 
@@ -199,67 +178,6 @@
         self.done.set()
         thread.exit()
 
-class ThreadedTCPSocketTest(SocketTCPTest, ThreadableTest):
-
-    def __init__(self, methodName='runTest'):
-        SocketTCPTest.__init__(self, methodName=methodName)
-        ThreadableTest.__init__(self)
-
-    def clientSetUp(self):
-        self.cli = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-
-    def clientTearDown(self):
-        self.cli.close()
-        self.cli = None
-        ThreadableTest.clientTearDown(self)
-
-class ThreadedUDPSocketTest(SocketUDPTest, ThreadableTest):
-
-    def __init__(self, methodName='runTest'):
-        SocketUDPTest.__init__(self, methodName=methodName)
-        ThreadableTest.__init__(self)
-
-    def clientSetUp(self):
-        self.cli = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
-
-    def clientTearDown(self):
-        self.cli.close()
-        self.cli = None
-        ThreadableTest.clientTearDown(self)
-
-class SocketConnectedTest(ThreadedTCPSocketTest):
-    """Socket tests for client-server connection.
-
-    self.cli_conn is a client socket connected to the server.  The
-    setUp() method guarantees that it is connected to the server.
-    """
-
-    def __init__(self, methodName='runTest'):
-        ThreadedTCPSocketTest.__init__(self, methodName=methodName)
-
-    def setUp(self):
-        ThreadedTCPSocketTest.setUp(self)
-        # Indicate explicitly we're ready for the client thread to
-        # proceed and then perform the blocking call to accept
-        self.serverExplicitReady()
-        conn, addr = self.serv.accept()
-        self.cli_conn = conn
-
-    def tearDown(self):
-        self.cli_conn.close()
-        self.cli_conn = None
-        ThreadedTCPSocketTest.tearDown(self)
-
-    def clientSetUp(self):
-        ThreadedTCPSocketTest.clientSetUp(self)
-        self.cli.connect((HOST, self.port))
-        self.serv_conn = self.cli
-
-    def clientTearDown(self):
-        self.serv_conn.close()
-        self.serv_conn = None
-        ThreadedTCPSocketTest.clientTearDown(self)
-
 class SocketPairTest(unittest.TestCase, ThreadableTest):
 
     def __init__(self, methodName='runTest'):
@@ -456,6 +374,25 @@
         return socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
 
 
+# Replacements for original test classes.
+
+class SocketUDPTest(UDPTestBase):
+    # Can delete this - it's not used at the time of writing.
+    pass
+
+class ThreadedUDPSocketTest(ThreadedSocketTestMixin, UDPTestBase):
+    pass
+
+class SocketTCPTest(SocketListeningTestMixin, TCPTestBase):
+    pass
+
+class ThreadedTCPSocketTest(ThreadedSocketTestMixin, SocketTCPTest):
+    pass
+
+class SocketConnectedTest(ConnectedStreamTestMixin, TCPTestBase):
+    pass
+
+
 # Test-skipping decorators for use with ThreadableTest.
 
 def skipWithClientIf(condition, reason):

From report at bugs.python.org  Mon Dec  6 21:53:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 20:53:18 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291668798.51.0.920627273789.issue9517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I just tried using script_helper in a new test, so I have a couple of comments.

I don't see stdout and stderr being conflated, it looks to me like they are returned separately, at least by the assert methods.

The assert methods return results, which is unlike other assert methods.  This is very useful, even essential, and I wouldn't want to give it up.  That conflicts with the current unittest conventions, though.

It would be a big help if 'err' were returned with the refcount line removed if it is there, which would make tests using the methods return the same 'err' regardless of whether they are run under a debug build or not.

I think the names of the two assert functions should follow the current unit test conventions (assertPythonRunOK and asssertPythonRunNotOK, perhaps?)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Mon Dec  6 21:59:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 20:59:14 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291669154.77.0.596310630811.issue9517@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Mon Dec  6 22:03:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Dec 2010 21:03:00 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1291668798.51.0.920627273789.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291669375.3579.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I just tried using script_helper in a new test, so I have a couple of
> comments.
> 
> I don't see stdout and stderr being conflated, it looks to me like
> they are returned separately, at least by the assert methods.

That's because I wrote the assert methods since this issue was opened :)

> It would be a big help if 'err' were returned with the refcount line
> removed if it is there, which would make tests using the methods
> return the same 'err' regardless of whether they are run under a debug
> build or not.

Indeed.

> I think the names of the two assert functions should follow the
> current unit test conventions (assertPythonRunOK and
> asssertPythonRunNotOK, perhaps?)

Well, they are functions, not methods, so I don't think they have to
follow the other convention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Mon Dec  6 22:12:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Dec 2010 21:12:03 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291608336.11.0.859331343079.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291669919.3579.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The problem of avoiding interfering with application level handlers
> while having unraisable errors visible by default is probably the
> biggest reason past attempts to get the standard library using the
> logging module internally haven't gained much traction :P

Isn't it a problem that the logging module should be designed to make
easy to fix or work around?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Mon Dec  6 23:23:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Dec 2010 22:23:49 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291674229.05.0.784264888971.issue10626@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Wow, I didn't realize that's how logging worked.  My understanding was a module should just get a logger and log messages, and if the application didn't do any setup beforehand, the first logging call would cause messages to be written to stdout (or stderr) in a default format.  In fact, I thought that I had observed that behavior in the past, but I just tested it and you are right, it complains about not having a handler.  

This definitely seems like a logging bug to me.  IMO the only thing a module should need to do is call getlogger with its qualified name and log messages.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Mon Dec  6 23:30:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Dec 2010 22:30:28 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291674229.05.0.784264888971.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291674623.3579.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Wow, I didn't realize that's how logging worked.  My understanding was
> a module should just get a logger and log messages, and if the
> application didn't do any setup beforehand, the first logging call
> would cause messages to be written to stdout (or stderr) in a default
> format.  In fact, I thought that I had observed that behavior in the
> past,

So have I. Did something change?

And does test_logging really have to change the whole logging setup,
rather than only what it needs to check for? Or can't it restore stuff
afterwards?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec  7 00:53:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 06 Dec 2010 23:53:51 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291679631.79.0.0979994059849.issue10548@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

(made slightly redundant by Holger's comment but I'll continue anyway)

I think the issue is that setUp / tearDown are used for two different purposes.

The first is setting up and tearing down test infrastructure - where you do want to see to errors.

The other is for asserting pre and post conditions. If these are expected to fail (for whatever reason) then it may be perfectly reasonable to mark them as expectedFailure.

The fact that it was reported as a bug, and also that Antoine has requested being able to skip in a tear down (separate issue) shows that people are doing this.

So on the one hand - a small proportion of tests are marked expectedFailure and a very small subset of those might have a test infrastructure setup error. On the other hand for people who want setUp to test pre-conditions and want expectedFailure to work here will be completely unable to do this. It seems like not having consistent behaviour for expectedFailure will be more of a problem for those who want it than having it would be for those who don't need it.

As expectedFailure is not intended to be widely used anyway I would rather have consistency. It also allows the implementation to be simplified by unifying skip / expected fail / exception handling for all of setUp / tearDown / testMethod / cleanUp.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Tue Dec  7 01:09:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 07 Dec 2010 00:09:02 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291680542.13.0.792442682422.issue8194@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I think, the file-like object behavior can be brought back. No need to handling gzipped file object in the patch, if the earlier behavior was not handling it. There is a separate issue to keep track of handling gzip encoded content in httplib.  I shall try to get this moving.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Tue Dec  7 01:15:41 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 07 Dec 2010 00:15:41 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
	buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>


New submission from David Bolen <db3l.net at gmail.com>:

On the XP and Win7 buildbots, kill_python sometimes fails to kill hung processes.  I caught one instance recently and gathered some information though not yet enough to identify the issue.  I can say that no processes are killed and no error messages displayed.  I think that implies either a process ownership-related snapshot failure (which can exit without error) or a failure to identify the processes.

I noticed issue10136 and considered it might be related, but in testing I found cases where the exact same usage of kill_python as this failing case worked fine, whereas if it was a path mismatch problem I would expect it to fail consistently. 

I have attached a log showing the hung processes, attempt to use kill_python, and final successful operation with the pskill utility.

In this case it was important to restore the buildbot quickly, but if I can catch it again I'll try to add some debugging code to kill_python first.

One thing that confused me along the way is that kill_python is only run at the beginning of a build and not as part of the clean process.  So there are cases where I have hung processes around, but they turn out to be killable when the next build starts.  I'm wondering if kill_python shouldn't perhaps be used on every clean operation too.

-- David

----------
components: Build
files: kill_python.log
messages: 123510
nosy: db3l
priority: normal
severity: normal
status: open
title: kill_python sometimes fails to kill processes on buildbots
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19964/kill_python.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Tue Dec  7 02:13:38 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Dec 2010 01:13:38 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291684418.77.0.187135116994.issue8194@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

The patch looks fine to me.  If it runs and everyone is happy, by all means lets put it in.

(I agree that the zlib stuff _should_ be handled elsewhere, but for reasons of expediency it was put into this module)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Tue Dec  7 02:33:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Dec 2010 01:33:36 +0000
Subject: [issue10626] test_concurrent_futures implicitly installs a logging
	handler on import
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291685616.74.0.481856534709.issue10626@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Actually, I take it back. The default state of logging appears to do the right thing with no special handler installed - both the .critical() and .exception() messages are written out to stderr by default, so the futures tests pass even after Brian's patch is applied.

So I think removing the handler installation code is the right thing to do, even if (as it turns out) it doesn't fix the test failure.

I also thought of a more minimal way to reproduce the test failure that makes it clear pydoc isn't really involved:

  ./python -m test test_concurrent_futures test_logging test_concurrent_futures

The first execution of the test will pass, the second will fail (both with and without Brian's patch to remove the handler installation).

Adding Vinay to the nosy list - I suspect Antoine is right that the logging tests are leaving existing loggers in a slightly unhealthy state. A better save/restore in regrtest.py might be a place to start, but I don't know the internals of the logging package well enough to improve on what I already added.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec  7 02:34:17 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Dec 2010 01:34:17 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291685657.91.0.374976907233.issue10626@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: test_concurrent_futures implicitly installs a logging handler on import -> Bad interaction between test_logging and test_concurrent_futures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec  7 03:08:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 02:08:30 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291687710.9.0.400770730617.issue10548@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have to say that it would never have occurred to me to assert a pre or post condition and an expected failure where I expected the pre or post condition to fail, but if you've got a real use case and it would make the code simpler, I suppose I have no serious objection.  I don't use expected failure myself.  Just make sure you document it well, since it is not a behavior I would expect when using expected failure, and I'm sure there will be others like me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Tue Dec  7 03:48:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 02:48:18 +0000
Subject: [issue1571170] Some numeric characters are still not recognized
Message-ID: <1291690098.03.0.564214681026.issue1571170@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Is there anything in this issue that is not addressed by #1571184?  It looks like this was originally reported on SF where bug reports and patches had separate ids, so this is probably a duplicate of #1571184.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571170>
_______________________________________

From report at bugs.python.org  Tue Dec  7 03:50:25 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 07 Dec 2010 02:50:25 +0000
Subject: [issue10487] http.server - doesn't process Status: header from CGI
	scripts
In-Reply-To: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>
Message-ID: <1291690225.03.0.699183672699.issue10487@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Just to mention, with the added code from issue 10482, I was able to get a 3-stream functionality working great in http.server and also backported it to 2.6 CGIHTTPServer... and to properly process the Status: header on stdout.

Works very well in 2.6; Issue 8077 prevents form processing from working in 3.2a4, but otherwise it is working there also, and the experience in 2.6 indicates that once issue 8077 is resolved, it should work in 3.2 also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10487>
_______________________________________

From report at bugs.python.org  Tue Dec  7 03:51:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 02:51:33 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291690293.1.0.205461139821.issue9517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, fine on the convention, but I'd still like a more memorable name for assert_python_failure.  I've been working on this issue off and on today, and I've had to look up that name at least four times.  I can remember assert_python_ok, but I can't remember whether its inverse is assert_python_fails, assert_python_bad, or what.  For some reason I haven't guessed 'failure' even once so far :)  (I know it's not assert_python_not_ok because I remember it isn't parallel...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Tue Dec  7 04:01:40 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 07 Dec 2010 03:01:40 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1291690900.2.0.77776332893.issue10482@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Looking at the code the way I've used it in my modified server.py:

            stderr = []
            stderr_thread = threading.Thread(target=self._readerthread,
                                             args=(p.stderr, stderr))
            stderr_thread.daemon = True
            stderr_thread.start()

            self.log_message("writer: %s" % str( nbytes ))
            stdin_thread = threading.Thread(target=self._writerthread,
                                            args=(self.rfile, p.stdin, nbytes))
            stdin_thread.daemon = True
            stdin_thread.start()

and later

            stderr_thread.join()
            stdin_thread.join()

            p.stderr.close()
            p.stdout.close()

            if stderr:
                stderr = stderr[ 0 ].decode("UTF-8")

It seems like this sort of code (possibly passing in the encoding) could be bundled back inside subprocess (I borrowed it from there).

It also seems from recent discussion on npopdev that the cheat-sheet "how to replace" other sys and os popen functions would be better done as wrapper functions for the various cases.  Someone pointed out that the hard cases probably aren't cross-platform, but that currently the easy cases all get harder when using subprocess than when using the deprecated facilities.  They shouldn't.  The names may need to be a bit more verbose to separate the various use cases, but each use case should remain at least as simple as the prior function.

So perhaps instead of just  subprocess.PIPE  to select particular handling for stdin, stdout, and stderr, subprocess should implement some varieties to handle attaching  different types of reader and writer threads to the handles... of course, parameters need to come along for the ride too: maybe the the additional variations would be object references with parameters supplied, instead of just a manifest constant like .PIPE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Tue Dec  7 04:26:38 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 07 Dec 2010 03:26:38 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1291692398.64.0.338254270305.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101207.zip is a new version of the regex module.

It includes additional checks against pathological regexes.

----------
Added file: http://bugs.python.org/file19965/issue2636-20101207.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec  7 04:35:20 2010
From: report at bugs.python.org (Donald Wallace Rouse II)
Date: Tue, 07 Dec 2010 03:35:20 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>


New submission from Donald Wallace Rouse II <python-bugs-as92jJ2 at dwr2.org>:

Python 2.7 programs crash on startup due to a defective third-party package installed in site-packages.

starting python 2.7 yields the following error message:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site.py", line 554, in <module>
    main()
  File "/usr/lib64/python2.7/site.py", line 537, in main
    known_paths = addsitepackages(known_paths)
  File "/usr/lib64/python2.7/site.py", line 316, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib64/python2.7/site.py", line 192, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib64/python2.7/site.py", line 162, in addpackage
    exec line
  File "<string>", line 1, in <module>
KeyError: 'zope'

A similar message appears when starting python2.7 interactively, but it then proceeds to the prompt (doesn't crash).

In the file .../python2.7/site.py, at about line 162, in the function "addpackage", you have an
unprotected "exec" line:
    if line.startswith(("import ", "import\t")):
        exec line

If the execution of the line fails, python generates an uncaught exception.
This places python at the mercy of bugs in third-party software.

The "exec" line should be bracketed by "try/except" to catch such errors:
    if line.startswith(("import ", "import\t")):
        try:
            exec line
        except:
            pass
        continue

Note 1: I am not sure whether this is a Distutils bug or Distutils2 bug (or even something else like "Extension Modules"), so I'm filing it under Distutils2. If this is incorrect, please forward to the proper place. Thanks.

Note 2: Here is where I initially reported this problem: http://bugs.gentoo.org/show_bug.cgi?id=347565

----------
assignee: tarek
components: Distutils2
messages: 123519
nosy: dwr2, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: site.py crashes on python startup due to defective .pth file
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Tue Dec  7 04:47:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 07 Dec 2010 03:47:37 +0000
Subject: [issue10630] dict_proxy.keys() / values() / items() are lists
In-Reply-To: <1291565946.17.0.111097012254.issue10630@psf.upfronthosting.co.za>
Message-ID: <1291693657.97.0.793981197742.issue10630@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r87107

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10630>
_______________________________________

From report at bugs.python.org  Tue Dec  7 05:01:13 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Dec 2010 04:01:13 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1291694473.43.0.768799007713.issue10482@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Or various incarnations of functools.partial applied to subprocess.Popen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Tue Dec  7 05:52:34 2010
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 07 Dec 2010 04:52:34 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1291697554.03.0.372541352193.issue5587@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Okay, I found it :-) Here is a new patch, now with a test.

----------
Added file: http://bugs.python.org/file19966/issue5587b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Tue Dec  7 07:54:23 2010
From: report at bugs.python.org (Johann Hanne)
Date: Tue, 07 Dec 2010 06:54:23 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291704863.99.0.41478894947.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

- Why is the generated pyconfig.h not good enough? Could we modify the ./configure script instead?
Probably setup.py needs to be extended; I did not have a deep look into the build system though

- the "empty.c" should remain empty... Why not use PC/WinMain.c instead?
It seems to be that MinGW does not support the wWinMain unicode entry point; the empty.c hack is just to show that it's actually linking

- why is a WinMain required when python.c is supposed to define a 
main()?
Good question; probably just a question of linker flags; I will have a look if my time permits

- Is the final binary a console application or a Windows application?
A Console application; creating a GUI application is easily done with the "-mwindows" gcc flag, but then you will have no Python console when not using idle or similar

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:02:44 2010
From: report at bugs.python.org (wojas)
Date: Tue, 07 Dec 2010 07:02:44 +0000
Subject: [issue10643] OSX proxy exceptions parse bug in urllib (crash)
In-Reply-To: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>
Message-ID: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>


New submission from wojas <python at m.wojas.nl>:

On OSX (tested with 10.6), urllib will fail to parse the proxy exceptions configuration if no netmask is specified.

On my system the following entries have been added to the proxy exception list: '127.0.0.1' and 'localhost'. The traceback in included below.

The problem:
 * In 'm = re.match(r"(\d+(?:\.\d+)*)(/\d+)?", value)' the netmask is optional
 * But 'mask = int(m.group(2)[1:])' implicitly assumes it exists.

This can be fixed by using 32 as a default netmask if none is specified, see attached patch: 'mask = int(m.group(2)[1:]) if m.group(2) else 32'

TRACEBACK:

  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 203, in open
    return self._mech_open(url, data, timeout=timeout)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 230, in _mech_open
    response = UserAgentBase.open(self, request, data)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_opener.py", line 188, in open
    req = meth(req)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_http.py", line 316, in http_request
    self.rfp.read()
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_http.py", line 242, in read
    f = self._opener.open(req)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 203, in open
    return self._mech_open(url, data, timeout=timeout)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py", line 230, in _mech_open
    response = UserAgentBase.open(self, request, data)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_opener.py", line 193, in open
    response = urlopen(self, req, data)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 344, in _open
    '_open', req)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 332, in _call_chain
    result = func(*args)
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 666, in <lambda>
    meth(r, proxy, type))
  File "/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py", line 678, in proxy_open
    if req.get_host() and self._proxy_bypass(req.get_host()):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py", line 1407, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py", line 1379, in proxy_bypass_macosx_sysconf
    mask = int(m.group(2)[1:])
TypeError: 'NoneType' object is unsubscriptable

----------
components: Extension Modules
files: urllib-osx-proxy-patch.diff
keywords: patch
messages: 123524
nosy: wojas
priority: normal
severity: normal
status: open
title: OSX proxy exceptions parse bug in urllib (crash)
versions: Python 2.6
Added file: http://bugs.python.org/file19967/urllib-osx-proxy-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10643>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:04:15 2010
From: report at bugs.python.org (wojas)
Date: Tue, 07 Dec 2010 07:04:15 +0000
Subject: [issue10643] OSX proxy exceptions parse bug in urllib (crash)
In-Reply-To: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>
Message-ID: <1291705455.37.0.342821172313.issue10643@psf.upfronthosting.co.za>


wojas <python at m.wojas.nl> added the comment:

Forgot to set bug type (crash).

----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10643>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:13:08 2010
From: report at bugs.python.org (Johann Hanne)
Date: Tue, 07 Dec 2010 07:13:08 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291705988.17.0.0770786888913.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

> However, if the patch doesn't manage to make "configure;make" work, it's IMO useless.
No, it's not, for two reasons:
- Embedding Python by just compiling/linking all the .c files in seems to be a major feature to me; so fixing compilation is useful for its own
- The win32 build system has never used "configure;make", but a Visual Studio project file; so why require it for a MinGW build?!

> Having "make install" work in some form would be desirable.
It would be a "nice to have". But there is one thing: The patch in its current form is trivial and next to impossible to break anything, yet I'm sure it's useful for a number of people. It's a result of work done within the company I'm working for. Submitting the patch does not have an immediate benefit for my company, it only will save me a (short!) amount of time because I will not to have to re-apply the patch for every new Python release. This time saving is the only justification for spending some working time to try to get it into the official tree.

As I have the feeling that all the discussion (which for the major part I used my spare time already...) is taking too much time, I will stop doing it as part of my job. As I'm privately interested in open source projects, I will continue to have a look at fixing "configure;make" for MinGW; but given my very limited spare time, this might take some weeks...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:17:14 2010
From: report at bugs.python.org (Zach Dwiel)
Date: Tue, 07 Dec 2010 07:17:14 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1291706234.87.0.192893974706.issue2636@psf.upfronthosting.co.za>


Zach Dwiel <zdwiel at gmail.com> added the comment:

Here is the terminal log of what happens when I try to install and then import regex.  Any ideas what is going on?

$ python setup.py install
running install
running build
running build_py
creating build
creating build/lib.linux-i686-2.6
copying Python2/regex.py -> build/lib.linux-i686-2.6
copying Python2/_regex_core.py -> build/lib.linux-i686-2.6
running build_ext
building '_regex' extension
creating build/temp.linux-i686-2.6
creating build/temp.linux-i686-2.6/Python2
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c Python2/_regex.c -o build/temp.linux-i686-2.6/Python2/_regex.o
Python2/_regex.c:109: warning: ?struct RE_State? declared inside parameter list
Python2/_regex.c:109: warning: its scope is only this definition or declaration, which is probably not what you want
Python2/_regex.c:110: warning: ?struct RE_State? declared inside parameter list
Python2/_regex.c:538: warning: initialization from incompatible pointer type
Python2/_regex.c:539: warning: initialization from incompatible pointer type
Python2/_regex.c:679: warning: initialization from incompatible pointer type
Python2/_regex.c:680: warning: initialization from incompatible pointer type
Python2/_regex.c:1217: warning: initialization from incompatible pointer type
Python2/_regex.c:1218: warning: initialization from incompatible pointer type
Python2/_regex.c: In function ?try_match?:
Python2/_regex.c:3153: warning: passing argument 1 of ?state->encoding->at_boundary? from incompatible pointer type
Python2/_regex.c:3153: note: expected ?struct RE_State *? but argument is of type ?struct RE_State *?
Python2/_regex.c:3184: warning: passing argument 1 of ?state->encoding->at_default_boundary? from incompatible pointer type
Python2/_regex.c:3184: note: expected ?struct RE_State *? but argument is of type ?struct RE_State *?
Python2/_regex.c: In function ?search_start?:
Python2/_regex.c:3535: warning: assignment from incompatible pointer type
Python2/_regex.c:3581: warning: assignment from incompatible pointer type
Python2/_regex.c: In function ?basic_match?:
Python2/_regex.c:3995: warning: assignment from incompatible pointer type
Python2/_regex.c:3996: warning: assignment from incompatible pointer type
Python2/_regex.c: At top level:
Python2/unicodedata_db.h:241: warning: ?nfc_first? defined but not used
Python2/unicodedata_db.h:448: warning: ?nfc_last? defined but not used
Python2/unicodedata_db.h:550: warning: ?decomp_prefix? defined but not used
Python2/unicodedata_db.h:2136: warning: ?decomp_data? defined but not used
Python2/unicodedata_db.h:3148: warning: ?decomp_index1? defined but not used
Python2/unicodedata_db.h:3333: warning: ?decomp_index2? defined but not used
Python2/unicodedata_db.h:4122: warning: ?comp_index? defined but not used
Python2/unicodedata_db.h:4241: warning: ?comp_data? defined but not used
Python2/unicodedata_db.h:5489: warning: ?get_change_3_2_0? defined but not used
Python2/unicodedata_db.h:5500: warning: ?normalization_3_2_0? defined but not used
Python2/_regex.c: In function ?basic_match?:
Python2/_regex.c:4106: warning: ?info.captures_count? may be used uninitialized in this function
Python2/_regex.c:4720: warning: ?info.captures_count? may be used uninitialized in this function
Python2/_regex.c: In function ?splitter_split?:
Python2/_regex.c:8076: warning: ?result? may be used uninitialized in this function
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-i686-2.6/Python2/_regex.o -o build/lib.linux-i686-2.6/_regex.so
running install_lib
copying build/lib.linux-i686-2.6/_regex.so -> /usr/local/lib/python2.6/dist-packages
copying build/lib.linux-i686-2.6/_regex_core.py -> /usr/local/lib/python2.6/dist-packages
copying build/lib.linux-i686-2.6/regex.py -> /usr/local/lib/python2.6/dist-packages
byte-compiling /usr/local/lib/python2.6/dist-packages/_regex_core.py to _regex_core.pyc
byte-compiling /usr/local/lib/python2.6/dist-packages/regex.py to regex.pyc
running install_egg_info
Writing /usr/local/lib/python2.6/dist-packages/regex-0.1.20101123.egg-info
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import regex
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/dist-packages/regex-0.1.20101207-py2.6-linux-i686.egg/regex.py", line 273, in <module>
    from _regex_core import *
  File "/usr/local/lib/python2.6/dist-packages/regex-0.1.20101207-py2.6-linux-i686.egg/_regex_core.py", line 54, in <module>
    import _regex
ImportError: /usr/local/lib/python2.6/dist-packages/regex-0.1.20101207-py2.6-linux-i686.egg/_regex.so: undefined symbol: max

----------
nosy: +zdwiel
type: feature request -> compile error
versions: +Python 2.6 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:22:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 07 Dec 2010 07:22:25 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291706545.33.0.494819790735.issue8194@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Instead of tossing around the GzipDecoding code from one method to another (which would in turn change the return value from those methods), I thought is appropriate to do a change in parse_response itself, so that it verifies that it is a http response (new kind) before attempting header retrieval. If it an old kind of response (a file object), it does not do a getheader call.

This is committed in r87111 for release27-maint. I shall merge this into other branches.

This does not change any return value from the methods.

- Tests look bit more involved than I expected. The correct way to test this would be to create a FakeTransport object which exhibited the previous older behavior of getting the response via http.getfile method. 

The Fakesocket and Transport tests are not actually testing the response. So I could not exercise the "response part".(Perhaps this is reason it was not caught in the first place). The request part are exercised properly.

If someone has a patch for the tests to exercise response of Fakesocket object and Transport class tests, welcome. Otherwise I shall try to come up with one and add this case too.

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:26:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 07 Dec 2010 07:26:56 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291706816.54.0.468954410673.issue8194@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This issue is not applicable to release31-maint.

----------
resolution:  -> fixed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Tue Dec  7 08:27:45 2010
From: report at bugs.python.org (Johann Hanne)
Date: Tue, 07 Dec 2010 07:27:45 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1291706865.83.0.307086916988.issue10615@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

Two corrections for the "configure;make" workaround:
- WRONG: Remove the created pyconfig.h and replace PC/pyconfig.h with the manually modified version I'm attaching
- CORRECT: Remove PC/pyconfig.h and replace the created pyconfig.h with the manually modified version I'm attaching
- Modules/config.c needs to modified as well:
-- Replace PyInit_posix by PyInit_nt (two occurences), "posix" by "nt" (in _PyImport_Inittab)
-- Remove '{"pwd", PyInit_pwd},' in _PyImport_Inittab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Tue Dec  7 09:46:13 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 07 Dec 2010 08:46:13 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
	buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1291711573.01.0.898277817288.issue10641@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

To kill python_d.exe, you should use kill_python_d.exe instead of
kill_python.exe.

> On the XP and Win7 buildbots, kill_python sometimes fails to kill hung
> processes.

Could you post the buildbot log url?

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Tue Dec  7 09:48:00 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 07 Dec 2010 08:48:00 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
	buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1291711680.75.0.60721760115.issue10641@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think #9973 is rather related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Tue Dec  7 09:49:01 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 07 Dec 2010 08:49:01 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1291711741.86.0.649571465155.issue9973@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file19968/py3k_buildbot_error_in_clean_faze_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Tue Dec  7 09:49:29 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 07 Dec 2010 08:49:29 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1291711769.87.0.306647855213.issue9973@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file19047/py3k_buildbot_error_in_clean_faze.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Tue Dec  7 09:59:51 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 07 Dec 2010 08:59:51 +0000
Subject: [issue10643] OSX proxy exceptions parse bug in urllib (crash)
In-Reply-To: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>
Message-ID: <1291712391.7.0.167543353556.issue10643@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The fix for this problem, originally reported in Issue8883, was released in Python 2.6.6.

----------
assignee:  -> ronaldoussoren
components: +Library (Lib), Macintosh -Extension Modules
nosy: +ned.deily, ronaldoussoren
resolution:  -> duplicate
status: open -> closed
superseder:  -> Proxy exception lookup fails on MacOS in urllib.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10643>
_______________________________________

From report at bugs.python.org  Tue Dec  7 10:01:26 2010
From: report at bugs.python.org (diekmann)
Date: Tue, 07 Dec 2010 09:01:26 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>


New submission from diekmann <diekmann at in.tum.de>:

Calling send()/sendall() on an invalid socket does not report an error and returns all bytes as written. Thus, all bytes written to the socket are lost and the application is not informed about that and treats the bytes as successfully sent. The bytes given to the socket are silently lost, this cannot be recovered.

The attached file includes an example to reproduce this problem. I defined an invalid socket, when the other side of the connection has closed the connection.

Steps to reproduce (see attached file for python implementation):
1) Create listening socket
2) let client connect to it
2.1) send something to the client (optional step)
3) Client terminates connection (now the socket on the server side is invalid)
4) Server calls send/sendall <--- No Error here, but everything is lost
5) Server calls send/sendall again (Now we get the required error)

----------
components: Library (Lib)
files: socketbug.py
messages: 123534
nosy: diekmann
priority: normal
severity: normal
status: open
title: socket loses data, calling send()/sendall() on invalid socket does not report error and returns all bytes as written
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file19969/socketbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Tue Dec  7 10:06:24 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 07 Dec 2010 09:06:24 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
	buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1291712784.84.0.541600751209.issue10641@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

> To kill python_d.exe, you should use kill_python_d.exe instead of
> kill_python.exe.

Crud, I thought I did.  Well, ok, so can't trust this test.

> Could you post the buildbot log url?

I think this is the last build in the sequence that was failing until I killed the processes:  http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2297  ... the processes had been around for maybe 45 hours at that point, but I can't find the last working run in the waterfall display (I get back to 2252 and then it sort of goes blank).

Maybe the main problem is just the sequencing ... the fact that kill_python is only used at the start of a build (but after the svn step) and not during the clean step at the end of a test run?  In this case since the svn step was failing it probably never got as far as running kill_python[_d].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Tue Dec  7 10:06:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 09:06:54 +0000
Subject: [issue10645] egg-info file in lib-dynload
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I just noticed that distutils creates an egg-info for the stdlib while installing Python.

This definitely happens for Python 2.7 and Python 3.2 (both framework builds on OSX).

In lib-dynload there is and egg-info file: "Python-2.7.1-py2.7.egg-info" 

Is this intentional? 

If it is: the OSX installer does not remove older versions when installing an upgrade (that is, I also have egg-info files for Python-2.7 and several pre-releases)

----------
assignee: tarek
components: Distutils
messages: 123536
nosy: eric.araujo, ronaldoussoren, tarek
priority: low
severity: normal
status: open
title: egg-info file in lib-dynload
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Tue Dec  7 10:12:16 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 07 Dec 2010 09:12:16 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
	buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1291713136.43.0.392937852063.issue10641@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

> I think #9973 is rather related.

Certainly could be another artifact of a python_d process still executing. In particular though, the suggested patch in that issue agrees with what I was thinking might be needed, in terms of moving kill_python_d over to clean.bat.

Can't think of any downsides of applying that change offhand, so if that were to be made, we could just then watch and wait to see if another hung condition occurred.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Tue Dec  7 10:15:24 2010
From: report at bugs.python.org (holger krekel)
Date: Tue, 07 Dec 2010 09:15:24 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291713324.6.0.0198354775728.issue10548@psf.upfronthosting.co.za>


holger krekel <holger.krekel at gmail.com> added the comment:

Michael, if you have it i'd like to see the original post/concrete use case. thanks, holger

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Tue Dec  7 11:27:52 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 07 Dec 2010 10:27:52 +0000
Subject: [issue10637] Calling CloseHandle twice	(Modules/posixmodule.c)
In-Reply-To: <1291608538.09.0.178759040649.issue10637@psf.upfronthosting.co.za>
Message-ID: <1291717672.63.0.349016304487.issue10637@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Committed in r87117(py3k).

----------
priority: release blocker -> 
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10637>
_______________________________________

From report at bugs.python.org  Tue Dec  7 11:32:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 07 Dec 2010 10:32:37 +0000
Subject: [issue9558] build_ext fails on VS8.0
In-Reply-To: <1281450935.69.0.209009694295.issue9558@psf.upfronthosting.co.za>
Message-ID: <1291717957.56.0.105622453006.issue9558@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Won't this go into python3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9558>
_______________________________________

From report at bugs.python.org  Tue Dec  7 12:13:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 07 Dec 2010 11:13:42 +0000
Subject: [issue9558] build_ext fails on VS8.0
In-Reply-To: <1281450935.69.0.209009694295.issue9558@psf.upfronthosting.co.za>
Message-ID: <1291720422.9.0.408962047087.issue9558@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I happen to have the same change in my workspace. Please apply this patch, it fixes the test suite when compiled with VS8.0.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9558>
_______________________________________

From report at bugs.python.org  Tue Dec  7 12:40:24 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Dec 2010 11:40:24 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291722024.26.0.676718139621.issue10626@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I will take a look at test_logging tidying up after itself, though the intention is to leave things as they were found (this is done in setUp/tearDown, and if it doesn't tidy up properly, that would be a bug).

As already explained in logging's documentation, there is no problem with just getting a logger and logging to it, BUT the top-level logger in any library package (and that includes stdlib, too) should have a NullHandler instance added to avoid the "no handlers could be found for logger XXX" message. This latter, one-off message is only there to guard against mis-configuration.

Re. Nick's comments about using logging in the stdlib - I'm not sure the reason he states is the reason for lack of traction, I think it's more to do with inertia. I will post separately on python-dev about use of logging in the stdlib itself, to see what specific obstacles stdlib maintainers see in the use of logging in their own modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec  7 13:12:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Dec 2010 12:12:30 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291723950.37.0.785012336323.issue10626@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, I think that comment was just a mistaken impression on my part.

Definitely something odd going on with the test interaction though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec  7 13:24:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 12:24:21 +0000
Subject: [issue9558] build_ext fails on VS8.0
In-Reply-To: <1281450935.69.0.209009694295.issue9558@psf.upfronthosting.co.za>
Message-ID: <1291724661.34.0.6003865413.issue9558@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the ping and the confirmation that it works.  Will check in shortly.

----------
components: +Distutils2
priority: normal -> high
status: open -> pending
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9558>
_______________________________________

From report at bugs.python.org  Tue Dec  7 13:25:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 12:25:59 +0000
Subject: [issue10645] egg-info file in lib-dynload
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1291724759.97.0.0431717035905.issue10645@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the existence of this file is intentional, to satisfy pkg_resources requirements for ?Python?.  Philip can confirm.

----------
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Tue Dec  7 13:41:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 12:41:11 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1291725671.88.0.676645338573.issue5587@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/issue5587>
_______________________________________

From report at bugs.python.org  Tue Dec  7 13:48:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 12:48:18 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1291726098.09.0.885222989015.issue10642@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> 
components: +Library (Lib) -Distutils2
type: crash -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Tue Dec  7 14:19:39 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 07 Dec 2010 13:19:39 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291727979.73.0.107321014846.issue8194@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Please also fix it in py3k branch in Lib/xmlrpc/client.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Tue Dec  7 14:31:46 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 07 Dec 2010 13:31:46 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1291728706.97.0.356442023372.issue10642@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/issue10642>
_______________________________________

From report at bugs.python.org  Tue Dec  7 14:36:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 13:36:22 +0000
Subject: [issue10643] OSX proxy exceptions parse bug in urllib (crash)
In-Reply-To: <1291705364.23.0.312464028826.issue10643@psf.upfronthosting.co.za>
Message-ID: <1291728982.73.0.517942022446.issue10643@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> committed/rejected
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10643>
_______________________________________

From report at bugs.python.org  Tue Dec  7 14:46:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Dec 2010 13:46:43 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291729603.81.0.626487985051.issue10644@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Which OS is it? It works for me:

Traceback (most recent call last):
  File "socketbug.py", line 24, in <module>
    print(con.send(bytes("Hello", "ascii")))
socket.error: [Errno 32] Broken pipe

Regardless, the error returned is the one returned by your OS here. If your OS accepts the send(), Python can nothing against it.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Tue Dec  7 14:50:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 13:50:10 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1291729810.78.0.814195359586.issue10642@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If the problem is in site.py it doesn't sound like a distutils bug at all.  I remember Victor doing something that changed the error handling/reporting when importing site.py, so I'm adding him as nosy.  I thought that was only in 3.x, though.  Does this not fail in 2.6?

----------
nosy: +haypo, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Tue Dec  7 15:02:05 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 07 Dec 2010 14:02:05 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1291730525.86.0.410760327666.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Oh, yes. I noticed that the pep3119 defines return value of method MutableMapping.keys() as Set, as well as method items(). So the implementation of dumb.keys() and dump.items() are not correct since they all return lists while the class inherits MutableMapping. 

The implementations in my patch should also be corrected since I made the same mistake. Besides, since issue6045 has already added get(), I need to update my patch. I will do it later.

And who can tell the specification of MutableMapping.update()? The pep3119 lacks of it. Should I follow the implementation in the ABC class MutableMapping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Tue Dec  7 15:08:01 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 14:08:01 +0000
Subject: [issue9227] can't import Tkinter / use IDLE after installing Python
	2.7 on Mac OS X
In-Reply-To: <1278883906.89.0.545374403914.issue9227@psf.upfronthosting.co.za>
Message-ID: <1291730881.69.0.823802046767.issue9227@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9227>
_______________________________________

From report at bugs.python.org  Tue Dec  7 15:14:18 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 14:14:18 +0000
Subject: [issue10107] Quitting IDLE on Mac doesn't save unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1291731258.47.0.252206746631.issue10107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: why does the patch change the signature of close_all_callback?

-    def close_all_callback(self, event):
+    def close_all_callback(self, *args, **kwds):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Tue Dec  7 15:18:04 2010
From: report at bugs.python.org (Julian Andres Klode)
Date: Tue, 07 Dec 2010 14:18:04 +0000
Subject: [issue2799] Remove _PyUnicode_AsString(),
	rework _PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
In-Reply-To: <1210329112.66.0.505096173761.issue2799@psf.upfronthosting.co.za>
Message-ID: <1291731484.69.0.595987855977.issue2799@psf.upfronthosting.co.za>


Julian Andres Klode <jak at jak-linux.org> added the comment:

The problem I see here is that there is no public way to simply get a C string from a unicode object similar to PyBytes_AsString() for bytes. That's bad because we don't want to rewrite the whole code to duplicate strings all the time and free every string we get from a MyPyUnicode_AsString() like function.

I used the following, but this clearly has a memory leak:


  static const char *MyPyUnicode_AsString(PyObject *op) {
      PyObject *bytes = PyUnicode_AsEncodedString(op,0,0);
      return bytes ? PyBytes_AS_STRING(bytes) : 0;
  }

I now use the following which has no memory leak, but needs an internal function (I would use _PyUnicode_AsString, but I need Python 2.X compatibility as well):

  static const char *MyPyUnicode_AsString(PyObject *op) {
      PyObject *bytes = _PyUnicode_AsDefaultEncodedString(op, 0);
      return bytes ? PyBytes_AS_STRING(bytes) : 0;
  }

So could something be done about this?

----------
nosy: +jak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2799>
_______________________________________

From report at bugs.python.org  Tue Dec  7 15:29:45 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 14:29:45 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1291732185.65.0.0179888629082.issue10154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

UTF-8 works on SuSE Enterprise Linux 9 and 10 as well. 

BTW, neither UTF8 nor UTF-8 work on HPUX 10. That platform requires spelling it as utf8. 

This sadly enought means that this code doesn't work on HPUX 10:

>>> locale.setlocale(locale.LC_ALL, locale.getdefaultlocale())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python2.7/lib/python2.7/locale.py", line 531, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

That's because getdefaultlocale returns 'UTF8' as the encoding, even though LANG is set to 'nl_NL.utf8' (which is a working locale on the machine I tested).

BTW. I'm +1 on changing the alias table as Marc-Andre proposed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Tue Dec  7 16:07:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Dec 2010 15:07:36 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291734456.27.0.405448156155.issue10580@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Changing "Completing" to "Complete" seems fine to me.

Here is a screenshot of where this currently appears: http://i.imgur.com/RX9b9.png

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Tue Dec  7 16:21:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 07 Dec 2010 15:21:20 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1291735280.66.0.102091785741.issue9129@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm okay classifying this as a security bug that should be fixed in the 2.6 tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Tue Dec  7 16:22:25 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 07 Dec 2010 15:22:25 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1291735345.26.0.823379362313.issue6706@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I do not see this as a security bug so no patch for 2.6 please.  (Comment requested from IRC).

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Tue Dec  7 16:28:32 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 15:28:32 +0000
Subject: [issue10107] Quitting IDLE on Mac doesn't save unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1291735712.23.0.934131671948.issue10107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: never mind the command callback has a different signature than a keybinding.

Committed the patch for 3.2 in r87119.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Tue Dec  7 16:56:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 15:56:14 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1291737374.11.0.990178921257.issue9523@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe that in the absence of other documentation the ABC is considered authoritative.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Tue Dec  7 16:58:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 15:58:43 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1291737523.06.0.856869581624.issue10404@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The patch binds the menu to Ctrl-Button-1 (that is, the way you open context menu's on OSX systems with a single button), however rightclick still doens't work (but does an X11-style paste operation).

I propose adding an explicit binding for button-2 as well:

            text.bind("<Control-Button-1>",self.right_menu_event)
            text.bind("<Button-2>",self.right_menu_event)

This ensures that the context menu can be opened using the expected mouse button.

An IMO additional bonus is that the odd X11-style pasting behaviour is disabled (that is, right-click is no longer equivalent to Cmd-V), although one could claim that this breaks backward compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Tue Dec  7 17:04:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 16:04:36 +0000
Subject: [issue10107] Quitting IDLE on Mac doesn't save unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1291737876.56.0.276751862362.issue10107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Merged to 3.1.x in r87120, merged to 2.7. in r87121.

Ned: thanks for looking into this, doubly so because Tk-on-OSX is involved.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Tue Dec  7 17:13:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 16:13:54 +0000
Subject: [issue10406] IDLE 2.7 on OS X does not enable Rstrip extension by
	default
In-Reply-To: <1289640402.26.0.448285710534.issue10406@psf.upfronthosting.co.za>
Message-ID: <1291738434.81.0.923994447516.issue10406@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Fixed in r87122.

Thanks you.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10406>
_______________________________________

From report at bugs.python.org  Tue Dec  7 17:17:18 2010
From: report at bugs.python.org (David Bolen)
Date: Tue, 07 Dec 2010 16:17:18 +0000
Subject: [issue9973] Sometimes buildbot fails to cleanup working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1291738638.04.0.970434570616.issue9973@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

I wonder if it might be better to have kill_python run at the tail end of test.bat, since there's a potential window where losing a connection to the build master might not run the clean step, so still risk blocking a future build after a reconnect due to still running processes.

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Tue Dec  7 17:37:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 07 Dec 2010 16:37:12 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1291739832.02.0.773764841875.issue8084@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

(reopening to ensure glyph's message doesn't get lost)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Tue Dec  7 17:59:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Dec 2010 16:59:40 +0000
Subject: [issue10646] ntpath.samefile doesn't work for hard links
In-Reply-To: <1291741179.93.0.790815222225.issue10646@psf.upfronthosting.co.za>
Message-ID: <1291741179.93.0.790815222225.issue10646@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

ntpath.samefile is currently implemented using GetFinalPathNameByHandle, which doesn't work for hard links.

Since I introduced values for os.stat().st_ino in #8879 (which implemented os.link), I suspect we can possibly change ntpath.samefile to be the same as posixfile.samefile and leave st_ino.


Hirokazu questioned whether or not that st_ino change was correct, but I think it will be fine on NTFS. As FAT does not support links anyways, there would be no issue with potential st_ino issues there as we wouldn't be comparing them for any reason.


(part of the reason I created this is that we have discussion on st_ino and samefile in a few different places and I'm losing track of where we're at)

----------
assignee: brian.curtin
components: Library (Lib), Windows
messages: 123564
nosy: brian.curtin, ocean-city
priority: normal
severity: normal
stage: unit test needed
status: open
title: ntpath.samefile doesn't work for hard links
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10646>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:14:24 2010
From: report at bugs.python.org (diekmann)
Date: Tue, 07 Dec 2010 17:14:24 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291742064.94.0.136837368204.issue10644@psf.upfronthosting.co.za>


diekmann <diekmann at in.tum.de> added the comment:

ubuntu 9.10 with python 3.1.1+ and debian 5.0.6 with Python 3.1.3rc1

I can reproduce the bug on both systems. Maybe it has been fixed in python 3.2?

----------
resolution: invalid -> 
status: pending -> open
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:19:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 17:19:26 +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: <1291742366.02.0.161646897124.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a revised version of the patch which also includes some tests.  Interestingly, the issue in syslog module is a regression from 3.1 introduced in r80401.  Although it is not a crasher, I don't think it was intentional because although openlog() is happy to accept NULL for indent, the error from  _PyUnicode_AsString() would have to be cleared if the intent was to ignore undecodable indent.

----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:19:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 17:19:42 +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: <1291742382.4.0.111578399102.issue6697@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file19970/issue6697a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:37:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Dec 2010 17:37:16 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291743436.41.0.531001069037.issue10644@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I tried on both 3.1.3 and 3.2. It works (raises an error) under Mandriva; I've just tested under Debian stable and it fails.

Looking at netstat, the difference seems to be that "nc" closes the TCP connection fine under Mandriva when killed, and doesn't under Debian. Again, Python only propagates whatever error code the OS does or doesn't return.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:44:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 07 Dec 2010 17:44:24 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <1291742366.02.0.161646897124.issue6697@psf.upfronthosting.co.za>
Message-ID: <4CFE726F.3080506@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I am attaching a revised version of the patch which also includes some tests.  Interestingly, the issue in syslog module is a regression from 3.1 introduced in r80401.  Although it is not a crasher, I don't think it was intentional because although openlog() is happy to accept NULL for indent, the error from  _PyUnicode_AsString() would have to be cleared if the intent was to ignore undecodable indent.

Some notes:

* Rather than just patching in error handling code, please consider
removing use of those APIs and replace their calls with something
more appropriate, e.g. using a parser API.

* When ignoring errors from the API, you have to clear the exception.
This is missing in a couple of places in the patch, e.g. in pyexpat.c

* Please also remove hacks like these:

+#define CMP PyUnicode_CompareWithASCIIString
+        if (CMP(nameobj, "entity") == 0)
+            res = self->entity;
+        else if (CMP(nameobj, "target") == 0)
+            res = self->target;
+        else if (CMP(nameobj, "version") == 0) {
+            return PyUnicode_FromFormat(
+                "Expat %d.%d.%d", XML_MAJOR_VERSION,
                 XML_MINOR_VERSION, XML_MICRO_VERSION);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:48:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 17:48:17 +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: <1291744097.62.0.40890865638.issue8654@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/issue8654>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:51:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 17:51:24 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1291744284.26.0.198924811309.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Daniel,

While these macros should not affect ABI, I would appreciate your feedback in light of your work on issue 8654.

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Dec  7 18:59:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 07 Dec 2010 17:59:20 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1291744760.61.0.0010676897873.issue10542@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

+1 on the general idea of abstracting out repeated code.

I will take a closer look at the details within the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Dec  7 19:03:47 2010
From: report at bugs.python.org (Pablo Bitton)
Date: Tue, 07 Dec 2010 18:03:47 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1291745027.38.0.76846159148.issue5673@psf.upfronthosting.co.za>


Pablo Bitton <pablo.bitton at gmail.com> added the comment:

Has anybody had a chance to look into the problem I encountered yet?

Do you need more information?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Tue Dec  7 19:04:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 07 Dec 2010 18:04:33 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1291745073.46.0.33485721442.issue10404@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Unfortunately, just adding the binding to <button-2> does not work because the Tk Text widget already has a documented binding of "paste-text" to <button-2> and this does not override that.  With the binding added, I found that the button-2 behavior for breakpoints did not work correctly as both events would be triggered and the resulting breakpoint lines were incorrect.  That, plus the compatibility issue, is why I thought it best to just stick to control-click.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Tue Dec  7 19:06:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 18:06:14 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <4CFE726F.3080506@egenix.com>
Message-ID: <AANLkTimc0OeKJR-St6GOSfJEorXRM4+5HDUhwh6eM6SU@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Dec 7, 2010 at 12:44 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> * Rather than just patching in error handling code, please consider
> removing use of those APIs and replace their calls with something
> more appropriate, e.g. using a parser API.
>
Yes, that's what I started doing in the "a" patch.  I am not sure what
you mean by "a parser API."  There are several places where conversion
is either unnecessary or an encoded string is already available.  See
_elementtree.c.

> * When ignoring errors from the API, you have to clear the exception.
> This is missing in a couple of places in the patch, e.g. in pyexpat.c
>

Right.  On the other hand, this is very similar to xmlparser_getattro
in _elementtree.c and I think should be handled the same way.

> * Please also remove hacks like these:
>
> +#define CMP PyUnicode_CompareWithASCIIString
> + ? ? ? ?if (CMP(nameobj, "entity") == 0)

What do you consider a hack?  The use of
PyUnicode_CompareWithASCIIString() or the shortening macro?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 19:11:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 07 Dec 2010 18:11:07 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <AANLkTimc0OeKJR-St6GOSfJEorXRM4+5HDUhwh6eM6SU@mail.gmail.com>
Message-ID: <4CFE78B9.4050606@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Tue, Dec 7, 2010 at 12:44 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>> * Rather than just patching in error handling code, please consider
>> removing use of those APIs and replace their calls with something
>> more appropriate, e.g. using a parser API.
>>
> Yes, that's what I started doing in the "a" patch.  I am not sure what
> you mean by "a parser API." 

PyArg_Parse() et al. See the discussion earlier on this ticket.

> There are several places where conversion
> is either unnecessary or an encoded string is already available.  See
> _elementtree.c.

If the API is not needed at all, even better.

>> * When ignoring errors from the API, you have to clear the exception.
>> This is missing in a couple of places in the patch, e.g. in pyexpat.c
>>
> 
> Right.  On the other hand, this is very similar to xmlparser_getattro
> in _elementtree.c and I think should be handled the same way.

Not sure what you mean here. If you ignore errors and don't clear
the exception, it will pop up at some later point in processing
and that's generally very confusing.

>> * Please also remove hacks like these:
>>
>> +#define CMP PyUnicode_CompareWithASCIIString
>> +        if (CMP(nameobj, "entity") == 0)
> 
> What do you consider a hack?  The use of
> PyUnicode_CompareWithASCIIString() or the shortening macro?

The shortening macro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 19:21:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 18:21:12 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <4CFE78B9.4050606@egenix.com>
Message-ID: <AANLkTi=qKxFm+tfXWqncuOgy+gG+GZ4mWXCteBUuL3_A@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Dec 7, 2010 at 1:11 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>> ?I am not sure what
>> you mean by "a parser API."
>
> PyArg_Parse() et al. See the discussion earlier on this ticket.
>

I've just realized that.  It is the "u#" code.  Yes, I'll see if I can
use it instead of "U", but I think in the affected code the PyUnicode
object is needed as well.

>> ..  this is very similar to xmlparser_getattro
>> in _elementtree.c and I think should be handled the same way.
>
> Not sure what you mean here. If you ignore errors and don't clear
> the exception, it will pop up at some later point in processing
> and that's generally very confusing.
>

I mean not converting to char* at all and use
PyUnicode_CompareWithASCIIString() instead of strcmp().  I wish that
function had a shorter name, though, but it is not a big deal to spell
it out.  BTW, I don't think there is a way to use wchar_t* literals in
Python code, right?  As in Py_UNICODE_strcmp(name, L"version").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 19:55:51 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Dec 2010 18:55:51 +0000
Subject: [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1291748151.97.0.428279550383.issue9129@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed for Python 2.6 in r87123.
Closing out as fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9129>
_______________________________________

From report at bugs.python.org  Tue Dec  7 20:02:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 07 Dec 2010 19:02:27 +0000
Subject: [issue6697] Check that _PyUnicode_AsString() result is not NULL
In-Reply-To: <AANLkTi=qKxFm+tfXWqncuOgy+gG+GZ4mWXCteBUuL3_A@mail.gmail.com>
Message-ID: <4CFE84C0.7020506@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Tue, Dec 7, 2010 at 1:11 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>>>  I am not sure what
>>> you mean by "a parser API."
>>
>> PyArg_Parse() et al. See the discussion earlier on this ticket.
>>
> 
> I've just realized that.  It is the "u#" code.  Yes, I'll see if I can
> use it instead of "U", but I think in the affected code the PyUnicode
> object is needed as well.
> 
>>> ..  this is very similar to xmlparser_getattro
>>> in _elementtree.c and I think should be handled the same way.
>>
>> Not sure what you mean here. If you ignore errors and don't clear
>> the exception, it will pop up at some later point in processing
>> and that's generally very confusing.
>>
> 
> I mean not converting to char* at all and use
> PyUnicode_CompareWithASCIIString() instead of strcmp().  I wish that
> function had a shorter name, though, but it is not a big deal to spell
> it out. 

Agreed; not my invention ;-) I would have used
PyUnicode_CompareToUTF8() or something along those lines.

> BTW, I don't think there is a way to use wchar_t* literals in
> Python code, right?  As in Py_UNICODE_strcmp(name, L"version").

No, since wchar_t may be something completely different than
Py_UNICODE.

No sure about today's situation, but at least a couple of years
ago wchar_t was not defined on all supported platforms, e.g.
Crays didn't have it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 20:25:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 07 Dec 2010 19:25:16 +0000
Subject: [issue1528154] New sequences for Unicode groups and block ranges
	needed
Message-ID: <1291749916.44.0.0288238989572.issue1528154@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg54865

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528154>
_______________________________________

From report at bugs.python.org  Tue Dec  7 20:28:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 07 Dec 2010 19:28:22 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291705988.17.0.0770786888913.issue10615@psf.upfronthosting.co.za>
Message-ID: <4CFE8AD4.8070902@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> - Embedding Python by just compiling/linking all the .c files in
> seems to be a major feature to me; so fixing compilation is useful
> for its own

If that's the objective of the patch, I'm -1 on it.

> - The win32 build system has never used "configure;make", but a
> Visual Studio project file; so why require it for a MinGW build?!

Well, if MingW could use the VS project files, that would be fine
with me as well... We need *some* build procedure. Just being
able to compile the source files is not maintainable.

> It would be a "nice to have". But there is one thing: The patch in
> its current form is trivial and next to impossible to break anything,
> yet I'm sure it's useful for a number of people. It's a result of
> work done within the company I'm working for. Submitting the patch
> does not have an immediate benefit for my company, it only will save
> me a (short!) amount of time because I will not to have to re-apply
> the patch for every new Python release. This time saving is the only
> justification for spending some working time to try to get it into
> the official tree.

Understood. Perhaps somebody else is interested in picking up the
patch.

BTW, you do have your employer's permission to contribute this work,
right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Tue Dec  7 21:12:58 2010
From: report at bugs.python.org (admin)
Date: Tue, 07 Dec 2010 20:12:58 +0000
Subject: [issue1528154] New sequences for Unicode groups and block ranges
	needed
Message-ID: <1291752778.96.0.871446672138.issue1528154@psf.upfronthosting.co.za>


admin <roundup-admin at psf.upfronthosting.co.za> merkte an:


note that posix uses a special set syntax, [:name:], for this purpose:

[:alnum:]   [:cntrl:]   [:lower:]   [:space:]
[:alpha:]   [:digit:]   [:print:]   [:upper:]
[:blank:]   [:graph:]   [:punct:]   [:xdigit:]

adding a new character escape will probably break more existing expressions, but no matter what syntax we chose, this is (micro-)PEP territory.

Removed message: http://bugs.python.org/msg54862

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528154>
_______________________________________

From report at bugs.python.org  Tue Dec  7 21:13:31 2010
From: report at bugs.python.org (admin)
Date: Tue, 07 Dec 2010 20:13:31 +0000
Subject: [issue1528154] New sequences for Unicode groups and block ranges
	needed
Message-ID: <1291752811.53.0.425995433985.issue1528154@psf.upfronthosting.co.za>


admin <roundup-admin at psf.upfronthosting.co.za> merkte an:

Logged In: YES 
user_id=38388

Could you make your request a little more specific ?

We already have catregories in the re module, so adding a
few more would be possible (patches are welcome !). However,
we do need to know why you need them and whether there are
other RE implementations that already have such special
matching characters, e.g. the Perl RE implementation.


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528154>
_______________________________________

From report at bugs.python.org  Tue Dec  7 21:42:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 20:42:59 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291754579.48.0.827721391588.issue10626@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec  7 21:47:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 20:47:45 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1291754865.64.0.369869751502.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I fixed my patch, thanks to a recent commit that showed me an example of PyErr_Format :)  All tests now pass.

----------
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19971/import-repr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Tue Dec  7 21:47:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Dec 2010 20:47:52 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1291754872.82.0.69488596124.issue8754@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19726/import-repr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Tue Dec  7 21:55:34 2010
From: report at bugs.python.org (Herm Fischer)
Date: Tue, 07 Dec 2010 20:55:34 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>


New submission from Herm Fischer <fischer at markv.com>:

My app has a tkinter messages listbox with a scrollbar which works fine in US setting, but not when locale is a European setting (with comma for decimal point).  It's a highly interactive app with a lot of number formattings in the local locale, and mostly used in Europe and Asia.

This instruction: self.logListBox.insert(END, message)

causes this crash in non-US locale when scrolling down:

Class: class Scrollbar(Widget):

    def set(self, *args):
        """Set the fractional values of the slider position (upper and
        lower ends as value between 0 and 1)."""
        self.tk.call((self._w, 'set') + args)   <<<<===== this line causes exception in European settings

the arg is in European decimal point format, when run on European settings, the error trace is:

  File "C:\Python31\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "C:\Python31\lib\tkinter\__init__.py", line 2797, in set
    self.tk.call((self._w, 'set') + args)
_tkinter.TclError: expected floating-point number but got "0,145833"

using python 3.1.3 (r313:86834)

----------
components: Tkinter
messages: 123580
nosy: hfischer
priority: normal
severity: normal
status: open
title: scrollbar crash in non-US locale format settings
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Tue Dec  7 22:11:17 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Dec 2010 21:11:17 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291756277.18.0.771335768824.issue10647@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Tue Dec  7 22:55:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 21:55:07 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291758907.36.0.742915206699.issue10647@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure what bug you are reporting here.  Are you saying that values using a , are automatically getting generated by tkinter and then rejected when fed back in?  If so, I suspect this is a tk problem, not tkinter problem, but someone would have to produce an equivalent tk/tcl program to prove it one way or another.  Can you produce a minimal test program that demonstrates the problem?  What version of tk/tcl are you using?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Tue Dec  7 23:04:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 22:04: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: <1291759456.3.0.997194196749.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

issue6697b.diff addresses Marc's comments.  Thanks for the review.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file19972/issue6697b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Tue Dec  7 23:31:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Dec 2010 22:31:15 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1291761075.36.0.848442724748.issue8754@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The patch looks same to me as far as I can judge. I would have used .format instead of %, but you wrote it ;-).

Seeing how many of our tests had to be patched convinced me that we should treat this like a feature request and only apply to 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Tue Dec  7 23:39:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 07 Dec 2010 22:39:56 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1291761596.57.0.680976760189.issue6632@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wish I discovered this issue when I was working on #10557!  Chances are I wouldn't have started a long python-dev thread rehashing the same issues as I see discussed here.

In any case, in #10557, I replaced core uses of PyUnicode_EncodeDecimal() with  PyUnicode_TransformDecimalToASCII() which transforms unicode to unicode.  There should not be any change in what digits builtin number types accept, but the C-API "codec" is defined to pass through anything that is not "Nd" while replacing Nd characters with the corresponding 0-9 digit.

String to string codecs including hex have been readded in r86934. See issue 7475.

----------
nosy: +belopolsky
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Wed Dec  8 00:03:41 2010
From: report at bugs.python.org (Herm Fischer)
Date: Tue, 07 Dec 2010 23:03:41 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291763021.19.0.991024521177.issue10647@psf.upfronthosting.co.za>


Herm Fischer <fischer at markv.com> added the comment:

The attached test case demonstrates this issue, run on pthyon 3.1.3 x64 and included tkinter.

When running on US Locale, runs fine.  Numbers have the period decimal point, no exceptions raised.

Then select control panel, "Language or Region", "Change keyboards and input methods", Formats tab, and I selected Dutch(Netherlands), press ok.  Rerun.  (I'm running under Eclipse, so exceptions do not terminate the program).  Note these exceptions as listbox is filled and autoscrolls, and as well, if you manually scroll, same exceptions get raised:

  File "C:\Python31\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "C:\Python31\lib\tkinter\__init__.py", line 2797, in set
    self.tk.call((self._w, 'set') + args)
_tkinter.TclError: expected floating-point number but got "0,02"

----------
Added file: http://bugs.python.org/file19973/ListboxScrollbarLocaleIssue.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Wed Dec  8 00:34:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Dec 2010 23:34:21 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291764861.62.0.326492021124.issue10647@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On gentoo linux with tcl/tk 8.5.8, if I use the following command line:

>LC_NUMERIC=fr_FR ../release31-maint/python ListboxScrollbarLocaleIssue.py

(which runs 3.1.3+) I can move the slider without any problem.  I confirmed that locale.format_string("%f", 0.30) produces 0,300000 after doing a setlocale at the python interactive prompt.  (I used fr_FR because I happen to have that locale installed, and I don't have Dutch installed).

So, so far I can't reproduce your problem.  I don't use eclipse, so eclipse related reproduction instructions won't work for me.

Note that when you say "exceptions don't terminate the program" I am assuming you mean it doesn't terminate eclipse.  You'd need to be starting python itself fresh to produce a valid test run.

What version of tk/tcl is your python compiled against?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Wed Dec  8 01:07:23 2010
From: report at bugs.python.org (Herm Fischer)
Date: Wed, 08 Dec 2010 00:07:23 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291766843.32.0.149915664037.issue10647@psf.upfronthosting.co.za>


Herm Fischer <fischer at markv.com> added the comment:

I'm using the 3.1.3 x64 of python.org

The dll's that came with it:

tck85.dll, version 8.5.2.2, created 8/10/2010
tk85.dll, version 8.5.2.2, same date

Is there a different way to get the version that is more helpful?

Is there an easy way to try the tcl/tk you are using (and distribute it to my users)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Wed Dec  8 02:25:51 2010
From: report at bugs.python.org (Demur Rumed)
Date: Wed, 08 Dec 2010 01:25:51 +0000
Subject: [issue10648] Extend peepholer to reverse loads or stores instead of
	build/unpack
In-Reply-To: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>
Message-ID: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

This modifies the peepholer's BUILD/UNPACK_SEQUENCE for the case when all stores are simple, or all loads are simple

It first scans to see if the pushing is done with simple LOADs. If so, it reverses the loads and removes the build unpack. If not, it scans ahead to see if it is followed by simple STOREs. If so, it reverses the stores and removes the build unpack

----------
components: Interpreter Core
files: peep.diff
keywords: patch
messages: 123588
nosy: serprex
priority: normal
severity: normal
status: open
title: Extend peepholer to reverse loads or stores instead of build/unpack
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19974/peep.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10648>
_______________________________________

From report at bugs.python.org  Wed Dec  8 02:30:35 2010
From: report at bugs.python.org (Chinmay Kanchi)
Date: Wed, 08 Dec 2010 01:30:35 +0000
Subject: [issue10649] Attempting to override special methods of a function
	object does not cause an error
In-Reply-To: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>
Message-ID: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>


New submission from Chinmay Kanchi <cgkanchi at gmail.com>:

Attempting to override a special method of an object of a builtin (like list) raises an AttributeError. This is obviously by design. However, doing the same to a user-defined function object seemingly replaces the function, but does not have the expected effect. In the interests of consistency, attempting to change a special method of a function object should raise an AttributeError stating that the property/method is read-only.

>>> a_list = list()
>>> a_list.__repr__ = lambda: '[]'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'list' object attribute '__repr__' is read-only

>>> def f(): pass
>>> f.__repr__ = lambda: 'f'
>>> f.__repr__
<function <lambda> at 0x6482b0>
>>> repr(f) #would expect it to return 'f' since no error was raised
'<function f at 0x6481f0>'
>>> f.__repr__() #so the change is half-way made, inconsistent and possibly problematic
'f'
>>>

----------
components: Interpreter Core
messages: 123589
nosy: Chinmay.Kanchi
priority: normal
severity: normal
status: open
title: Attempting to override special methods of a function object does not cause an error
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10649>
_______________________________________

From report at bugs.python.org  Wed Dec  8 02:33:08 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Dec 2010 01:33:08 +0000
Subject: [issue10648] Extend peepholer to reverse loads or stores instead of
	build/unpack
In-Reply-To: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>
Message-ID: <1291771988.2.0.229458282868.issue10648@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10648>
_______________________________________

From report at bugs.python.org  Wed Dec  8 03:08:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 02:08:45 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1291774125.34.0.245094154598.issue10647@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it sounds like you are on Windows, which is a platform I'm not all that familiar with.  I think we bundle TK for the windows installer, but I'm not 100% sure.  I think to use a different version you have to recompile Python, which on Windows is a non-trivial undertaking (but entirely possible).  I'm adding a couple of windows people to nosy, perhaps they will have some thoughts.

----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Wed Dec  8 03:29:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 02:29:45 +0000
Subject: [issue10649] Attempting to override special methods of a function
	object does not cause an error
In-Reply-To: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>
Message-ID: <1291775385.57.0.557964972703.issue10649@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As you observe, the attribute is not read only, it simply isn't referred to when special method lookup is done.  This is specified as part of the language design for new style classes, but has only been made consistently true in recent versions.

On on the other hand, the special methods are not special in regard to their read-only nature on builtin types:

>>> l = list()
>>> l.append = '1'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'list' object attribute 'append' is read-only

Thus, this is not a bug, it's just the way the language works.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10649>
_______________________________________

From report at bugs.python.org  Wed Dec  8 05:02:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Dec 2010 04:02:49 +0000
Subject: [issue10648] Extend peepholer to reverse loads or stores instead of
	build/unpack
In-Reply-To: <1291771551.8.0.926490370256.issue10648@psf.upfronthosting.co.za>
Message-ID: <1291780969.45.0.232301475742.issue10648@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the patch.  I had looked at this long ago when I first added the ROT2 optimization and the ROT3/ROT2 optimization.  It wasn't included because it wasn't worth the added complexity in the peepholer logic and because there were concerns about executing internally in a different order than specified by the code.

Since LOAD_NAME and LOAD_GLOBAL are subject to user control, changing their order of evaluation causes a visible change in semantics.  For example, the following result is different than before the patch.

>>> class Dict(dict):
...     def __getitem__(self, key):
...          print(key)
...          return dict.__getitem__(self, key)
...
>>> ns = Dict()
>>> exec('c=1; d=2; a,b=c,d', globals(), ns)
d
c

For the most part, I'm not too excited about the patch because
* it is limited to very simple cases that already have some optimization
* it needs to be limited even further to be semantically neutral
* it adds complexity to a part of the peepholer that is already a bit too complicated (the more peephole assumptions we make, the harder it is to maintain, especially when opcodes are added, deleted, or changed).
* changing order of execution starts to venture into territory that we've stayed away from (on purpose).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10648>
_______________________________________

From report at bugs.python.org  Wed Dec  8 09:05:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 08 Dec 2010 08:05:13 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1291795513.0.0.328160678847.issue8194@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

py3k fixed in r87128

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Wed Dec  8 09:21:38 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Dec 2010 08:21:38 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1291796498.24.0.227651948238.issue10404@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Yet another prove of how much Tk sucks on OSX.

I'm not too happy about only binding Ctrl+<button-1>, because users will expect that this is means that <button-2> works as well. But if we cannot disable the default <button-2> binding we'll have to live with this crap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Wed Dec  8 09:22:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Dec 2010 08:22:10 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1291796530.08.0.573422211635.issue10404@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Oops, 's/prove/proof/'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Wed Dec  8 10:00:21 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Dec 2010 09:00:21 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1291798821.3.0.92402773825.issue10404@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It could be worse.  As I noted in Issue10405, the IDLE breakpoint facility appears to be officially undocumented on any platform so it's hard to know what users' expectations are.  And there are still Macs out there with only one button.  As a side note, there are still OS X X11 versions of Tkinter for current Python releases; for example, the default MacPorts Tk configuration is X11-based; it does have the advantage of working without quirks in 64-bit builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Wed Dec  8 11:17:10 2010
From: report at bugs.python.org (diekmann)
Date: Wed, 08 Dec 2010 10:17:10 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291803430.7.0.25296396852.issue10644@psf.upfronthosting.co.za>


diekmann <diekmann at in.tum.de> added the comment:

The Documentation states:

socket.sendall(bytes[, flags])?
    Send data to the socket. The socket must be connected to a remote socket. The optional flags argument has the same meaning as for recv() above. Unlike send(), this method continues to send data from bytes until either all data has been sent or an error occurs. None is returned on success. On error, an exception is raised, and there is no way to determine how much data, if any, was successfully sent.

This is not consistent with the results reproduced above, however, the results from above are exactly what should happen. Maybe there should be a remark, that the return value of sendall (and send) may be system dependent. Or a patch which enforces the documented behviour of sendall, regardless of the operating system would be a nice future feature?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Wed Dec  8 11:26:21 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 08 Dec 2010 10:26:21 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1291803981.93.0.578773236564.issue10548@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, the original report is here:

http://code.google.com/p/unittest-ext/issues/detail?id=21

I copied all the details provided into this issue though. Obviously the original reporter feels that they have a genuine use case.

There is also issue 9857 where Antoine is asking for test skipping in a tearDown. His use case works just as well for wanting to mark an expected fail in a tearDown (or a clean up function). As soon as we allow skips in tearDown / cleanUp functions it seems wise to also allow them in setUps for consistency (otherwise it becomes difficult to remember which parts of the test can skip, which can be expected fail etc):

http://bugs.python.org/issue9857

Raising SkipTest when in a tearDown method is reported as an error, rather than a skipped test.
Now doing this sounds like a weird use case, but it would be actually useful when you have a worker thread, and the tearDown method collects the exception raised in that thread and raises it again. For the worker thread to be able to use skipTest(), a SkipTest exception raised in tearDown should be properly reported as a skip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Wed Dec  8 11:51:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Dec 2010 10:51:03 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291803430.7.0.25296396852.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291805457.3547.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is not consistent with the results reproduced above, however, the
> results from above are exactly what should happen. Maybe there should
> be a remark, that the return value of sendall (and send) may be system
> dependent.

Pretty much all the socket module is system-dependent, and it is
actually stated at the top of the documentation:

?Some behavior may be platform dependent, since calls are made to the
operating system socket APIs.?
http://docs.python.org/dev/library/socket.html

> Or a patch which enforces the documented behviour of sendall,
> regardless of the operating system would be a nice future feature?

How could it work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Wed Dec  8 13:24:00 2010
From: report at bugs.python.org (diekmann)
Date: Wed, 08 Dec 2010 12:24:00 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291811040.62.0.133542021624.issue10644@psf.upfronthosting.co.za>


diekmann <diekmann at in.tum.de> added the comment:

> How could it work?
Before sending the actual data to the socket, send an empty packet to the socket and check if it is still alive. This may be a large performance issue on a lower level (if the connection is TCP, we want to wait for the ACK), but on a higher level, when using sendall() with larger arguments, it may be very convenient and the performance overhead may be barely noticeable.
I guess when using high-level functions like sendall(), the bare funcionality is preferred over this performance issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Wed Dec  8 14:14:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 13:14:53 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291814093.55.0.798394635221.issue9517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a patch that causes _assert_python to remove the refcount lines from stderr.

----------
keywords: +patch
Added file: http://bugs.python.org/file19975/script_helper_del_refcount.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Wed Dec  8 14:22:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 13:22:58 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291814578.53.0.275140857888.issue9517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Having posted that it occurs to me that it could be useful to have the _remove_refcount function in test.support as remove_refcount instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Wed Dec  8 14:56:15 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 08 Dec 2010 13:56:15 +0000
Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0
In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>
Message-ID: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I'm not sure if this is a documentation issue or a bug. If watchexp=0,
quantize() also allows any number of digits:


>>> x = Decimal("6885998238912213556789006667970467609814")
>>> y = Decimal("1e2")
>>> x.quantize(y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/decimal.py", line 2488, in quantize
    'quantize result has too many digits for current context')
  File "/usr/local/lib/python3.2/decimal.py", line 3925, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: quantize result has too many digits for current context
>>> 
>>> x.quantize(y, watchexp=0)
Decimal('6.8859982389122135567890066679704676098E+39')

----------
components: Library (Lib)
messages: 123603
nosy: mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: decimal.py: quantize(): excess digits with watchexp=0
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10650>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:01:53 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 08 Dec 2010 14:01:53 +0000
Subject: [issue10517] test_concurrent_futures crashes with "Fatal Python
	error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1291816913.92.0.0760308244013.issue10517@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Couldn't repro this on my debian 5.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:15:50 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 14:15:50 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1291817750.17.0.880095341241.issue8533@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, can this go into Python3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:24:04 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 14:24:04 +0000
Subject: [issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1291818244.99.0.528927807732.issue10566@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

This is very interesting work - thank you!

Sorry for not commenting earlier (very busy), so here are my thoughts so far.

The baseline for the diff appears to be against the py3k branch, in that it adds back in classes from 2.*: PyIntObject.

There's currently some deliberate divergence between the code in the 2.7 branch and the py3k branch.  For example, in the 2.7 branch, we pretty-print PyUnicodeObject instances with a u'' prefix, whereas in the py3k branch we pretty-print them plainly: the code is trying to mimic the underlying syntax of a particular version of the python language in the inferior process.  (In both cases though, the gdb code is for python 2)

Are you attempting to support both python 2 and python 3 (in the inferior process) from the same code?

Going through the individual parts of the patch:

Do the changes to "pretty_printer_lookup" slow things down, I wonder?  (It has to be called every time gdb print a pointer)

"py-globals" looks like a nice addition, though I feel there should be an abstract base class for PyLocals and PyGlobals to inherit from ("PyNamespaceCommand", perhaps, though that sucks as a name).

The "py-break" command looks very useful  Unfortunately, AIUI we're in feature freeze for 3.2 now (sorry not to get to this earlier), and I have some fears about compatibility with all of the different versions of gdb 7 that are out there.  What versions of gdb have you tested this with?

_LoggingState looks interesting; getting the various versions of gdb to capture output as a python string can be challenging.  In particular, I've run into problems with buffering of large amounts of output; see: https://bugzilla.redhat.com/show_bug.cgi?id=620930

get_selected_inferior() clearly is impacted by gdb bugs, so I'm warying about merging that
Likewise for GenericCodeStepper.init_breakpoints (probably should refrain from swearing in comments, if nothing else, it's a dead give away that the code needs more work :)  I don't know if we have any rules about it, but I don't remember seeing such "colorful" language before in python's sources)

I notice that the selftests use skip_unless_7_2_decorator on the tests for py-break, py-step, py-next and py-exec.  If these commands only work on a sufficiently recent version of gdb, should the commands themselves also be wrapped in a conditional?   Either not registering them if gdb doesn't have the support, or perhaps registering a fallback that says "gdb not recent enough", or somesuch.  Part of gdb's UI is tab-completion, and it's nice for "py-[TAB]" to present all useful options.  That makes me think that we shouldn't register commands that are known to be incompatible with the running gdb version.

This is exciting work, in that gdb seems to be getting significantly more powerful, and the debug hooks are advancing to take advantage of it.  Unfortunately, given that Tools/gdb/libpython.py is part of the python source tree, it's arguably governed by the same feature freeze rules as the rest of Python (e.g. no new features in 2.7).  I wonder if an exception can be made for it, given that this code is a support tool that runs in a different process to the main python build, potentially for a different major-release of python.   (At some point we'll want to port gdb to python 3, which I'm not looking forward to...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:36:17 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 08 Dec 2010 14:36:17 +0000
Subject: [issue10650] decimal.py: quantize(): excess digits with watchexp=0
In-Reply-To: <1291816575.32.0.784106881295.issue10650@psf.upfronthosting.co.za>
Message-ID: <1291818977.61.0.311315912409.issue10650@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

NaNs, however, are decapitated:

>>> x = Decimal("NaN5357671565858315212612021522416387828577")
>>> y = 0
>>> x.quantize(y, watchexp=0)
Decimal('NaN8315212612021522416387828577')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10650>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:39:36 2010
From: report at bugs.python.org (Vladimir K)
Date: Wed, 08 Dec 2010 14:39:36 +0000
Subject: [issue10651] chr(13) is added before chr(10) when issuing ".write"
	under windows
In-Reply-To: <1291819176.76.0.271161010974.issue10651@psf.upfronthosting.co.za>
Message-ID: <1291819176.76.0.271161010974.issue10651@psf.upfronthosting.co.za>


New submission from Vladimir K <kzm362 at yahoo.com>:

The following code (see attached file) was intended to remove chr(13) from end-of-lines under Windows to make the file Unix-compliant but it always appends chr(13) before chr(10).

I'm under Windows XP.

----------
components: IO, Windows
files: chr13remove.py
messages: 123608
nosy: KZM
priority: normal
severity: normal
status: open
title: chr(13) is added before chr(10) when issuing ".write" under windows
versions: Python 2.7
Added file: http://bugs.python.org/file19976/chr13remove.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10651>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:39:59 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 14:39:59 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

On official Python3.2 beta1 windows binary, I noticed following
command fails. (test_tcl alone won't fail)

I couldn't reproduce this on binary built from source without
installation.

//////////////////////////////////////////////////////////////

C:\Python32>.\python.exe -m test.regrtest -v test___all__ test_tcl

(snip)

[2/2] test_tcl
testCall (test.test_tcl.TclTest) ... ERROR
testCallException (test.test_tcl.TclTest) ... ERROR
testCallException2 (test.test_tcl.TclTest) ... ERROR
testEval (test.test_tcl.TclTest) ... ERROR
testEvalException (test.test_tcl.TclTest) ... ERROR
testEvalException2 (test.test_tcl.TclTest) ... ERROR
testEvalFile (test.test_tcl.TclTest) ... ERROR
testEvalFileException (test.test_tcl.TclTest) ... ERROR
testGetVar (test.test_tcl.TclTest) ... ERROR
testGetVarArray (test.test_tcl.TclTest) ... ERROR
testGetVarArrayException (test.test_tcl.TclTest) ... ERROR
testGetVarException (test.test_tcl.TclTest) ... ERROR
testLoadWithUNC (test.test_tcl.TclTest) ... ERROR
testPackageRequireException (test.test_tcl.TclTest) ... ERROR
testSetVar (test.test_tcl.TclTest) ... ERROR
testSetVarArray (test.test_tcl.TclTest) ... ERROR
testUnsetVar (test.test_tcl.TclTest) ... ERROR
testUnsetVarArray (test.test_tcl.TclTest) ... ERROR
testUnsetVarException (test.test_tcl.TclTest) ... ERROR
testFlattenLen (test.test_tcl.TkinterTest) ... ok

======================================================================
ERROR: testCall (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_tcl.py", line 25, in setUp
    self.interp = Tcl()
  File "C:\Python32\lib\tkinter\__init__.py", line 1768, in Tcl
    return Tk(screenName, baseName, className, useTk)
  File "C:\Python32\lib\tkinter\__init__.py", line 1674, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
    C:/Python32/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library C:/
tcl8.5.2/library C:/tcl8.5.2/library



This probably means that Tcl wasn't installed properly.


(snip)

----------------------------------------------------------------------
Ran 20 tests in 1.752s

FAILED (errors=19)
test test_tcl failed -- multiple errors occurred
1 test failed:
    test_tcl
1 test altered the execution environment:
    test___all__

----------
components: Tests, Windows
messages: 123609
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test___all_ + test_tcl fails (Windows installed binary)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:49:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Dec 2010 14:49:05 +0000
Subject: [issue10651] chr(13) is added before chr(10) when issuing ".write"
	under windows
In-Reply-To: <1291819176.76.0.271161010974.issue10651@psf.upfronthosting.co.za>
Message-ID: <1291819745.38.0.793839752918.issue10651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

On Windows, newlines in text files are always translated. Please read
http://docs.python.org/tutorial/inputoutput.html#reading-and-writing-files

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10651>
_______________________________________

From report at bugs.python.org  Wed Dec  8 15:56:40 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 14:56:40 +0000
Subject: [issue1705520] API for excluding methods from unittest stack traces
Message-ID: <1291820200.16.0.737156837927.issue1705520@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/issue1705520>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:00:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Dec 2010 15:00:24 +0000
Subject: [issue10649] Attempting to override special methods of a function
	object does not cause an error
In-Reply-To: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>
Message-ID: <1291820424.87.0.374755134654.issue10649@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

More info:
http://docs.python.org/dev/reference/datamodel#special-method-names
http://docs.python.org/dev/reference/datamodel#special-method-lookup-for-new-style-classes

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10649>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:01:31 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:01:31 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Following tests fails on official Python3.2 Windows binary.

I cannot reproduce this on VC6.

/////////////////////////////////////////////////////

C:\Python32>.\python -m test.regrtest -v test_time test_strptime

[1/2] test_time
test_asctime (test.test_time.TimeTestCase) ... ok
test_asctime_bounding_check (test.test_time.TimeTestCase) ... ok
test_clock (test.test_time.TimeTestCase) ... ok
test_conversions (test.test_time.TimeTestCase) ... ok
test_ctime_without_arg (test.test_time.TimeTestCase) ... ok
test_data_attributes (test.test_time.TimeTestCase) ... ok
test_default_values_for_zero (test.test_time.TimeTestCase) ... ok
test_gmtime_without_arg (test.test_time.TimeTestCase) ... ok
test_insane_timestamps (test.test_time.TimeTestCase) ... ok
test_localtime_without_arg (test.test_time.TimeTestCase) ... ok
test_sleep (test.test_time.TimeTestCase) ... ok
test_strftime (test.test_time.TimeTestCase) ... ok
test_strftime_bounding_check (test.test_time.TimeTestCase) ... ok
test_strptime (test.test_time.TimeTestCase) ... FAIL
test_strptime_bytes (test.test_time.TimeTestCase) ... ok
test_tzset (test.test_time.TimeTestCase) ... ok
test_bug_3061 (test.test_time.TestLocale) ... ok

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
test test_time crashed -- <class 'UnicodeEncodeError'>: 'cp932' codec can't enco
de character '\x93' in position 495: illegal multibyte sequence
Traceback (most recent call last):
  File "C:\Python32\lib\test\regrtest.py", line 960, in runtest_inner
    indirect_test()
  File "C:\Python32\lib\test\test_time.py", line 244, in test_main
    support.run_unittest(TimeTestCase, TestLocale)
  File "C:\Python32\lib\test\support.py", line 1146, in run_unittest
    _run_suite(suite)
  File "C:\Python32\lib\test\support.py", line 1120, in _run_suite
    result = runner.run(suite)
  File "C:\Python32\lib\unittest\runner.py", line 173, in run
    result.printErrors()
  File "C:\Python32\lib\unittest\runner.py", line 110, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "C:\Python32\lib\unittest\runner.py", line 117, in printErrorList
    self.stream.writeln("%s" % err)
  File "C:\Python32\lib\unittest\runner.py", line 25, in writeln
    self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in position 495:
 illegal multibyte sequence
[2/2] test_strptime
test_basic (test.test_strptime.getlang_Tests) ... ok
test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok
test_date_time (test.test_strptime.LocaleTime_Tests) ... ok
test_lang (test.test_strptime.LocaleTime_Tests) ... ok
test_month (test.test_strptime.LocaleTime_Tests) ... ok
test_timezone (test.test_strptime.LocaleTime_Tests) ... FAIL
test_weekday (test.test_strptime.LocaleTime_Tests) ... ok
test_blankpattern (test.test_strptime.TimeRETests) ... ok
test_compile (test.test_strptime.TimeRETests) ... FAIL
test_locale_data_w_regex_metacharacters (test.test_strptime.TimeRETests) ... ok
test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok
test_pattern (test.test_strptime.TimeRETests) ... ok
test_pattern_escaping (test.test_strptime.TimeRETests) ... ok
test_whitespace_substitution (test.test_strptime.TimeRETests) ... ok
test_ValueError (test.test_strptime.StrptimeTests) ... ok
test_bad_timezone (test.test_strptime.StrptimeTests) ... ok
test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok
test_date (test.test_strptime.StrptimeTests) ... ok
test_date_time (test.test_strptime.StrptimeTests) ... ok
test_day (test.test_strptime.StrptimeTests) ... ok
test_defaults (test.test_strptime.StrptimeTests) ... ok
test_escaping (test.test_strptime.StrptimeTests) ... ok
test_fraction (test.test_strptime.StrptimeTests) ... ok
test_hour (test.test_strptime.StrptimeTests) ... ok
test_julian (test.test_strptime.StrptimeTests) ... ok
test_minute (test.test_strptime.StrptimeTests) ... ok
test_month (test.test_strptime.StrptimeTests) ... ok
test_percent (test.test_strptime.StrptimeTests) ... ok
test_second (test.test_strptime.StrptimeTests) ... ok
test_time (test.test_strptime.StrptimeTests) ... ok
test_timezone (test.test_strptime.StrptimeTests) ... ERROR
test_unconverteddata (test.test_strptime.StrptimeTests) ... ok
test_weekday (test.test_strptime.StrptimeTests) ... ok
test_year (test.test_strptime.StrptimeTests) ... ok
test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok
test_all_julian_days (test.test_strptime.JulianTests) ... ok
test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ERROR
test_gregorian_calculation (test.test_strptime.CalculationTests) ... ERROR
test_julian_calculation (test.test_strptime.CalculationTests) ... ERROR
test_week_of_year_and_day_of_week_calculation (test.test_strptime.CalculationTes
ts) ... ok
test_TimeRE_recreation (test.test_strptime.CacheTests) ... ok
test_new_localetime (test.test_strptime.CacheTests) ... ok
test_regex_cleanup (test.test_strptime.CacheTests) ... ok
test_time_re_recreation (test.test_strptime.CacheTests) ... ok

======================================================================
ERROR: test_timezone (test.test_strptime.StrptimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 303, in test_timezone
    strp_output = _strptime._strptime_time(strf_output, "%Z")
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)' does not match
format '%Z'

======================================================================
ERROR: test_day_of_week_calculation (test.test_strptime.CalculationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 437, in test_day_of_week_ca
lculation
    format_string)
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '2010 12 08 14 00 342 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\
x9e)' does not match format '%Y %m %d %H %S %j %Z'

======================================================================
ERROR: test_gregorian_calculation (test.test_strptime.CalculationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 423, in test_gregorian_calc
ulation
    format_string)
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '2010 14 58 01 3 342 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x
9e)' does not match format '%Y %H %M %S %w %j %Z'

======================================================================
ERROR: test_julian_calculation (test.test_strptime.CalculationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python32\lib\test\test_strptime.py", line 414, in test_julian_calcula
tion
    format_string)
  File "C:\Python32\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\Python32\lib\_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '2010 12 08 14 58 01 3 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e
\x9e)' does not match format '%Y %m %d %H %M %S %w %Z'

======================================================================
FAIL: test_timezone (test.test_strptime.LocaleTime_Tests)
----------------------------------------------------------------------
test test_strptime crashed -- <class 'UnicodeEncodeError'>: 'cp932' codec can't
encode character '\x93' in position 192: illegal multibyte sequence
Traceback (most recent call last):
  File "C:\Python32\lib\test\regrtest.py", line 960, in runtest_inner
    indirect_test()
  File "C:\Python32\lib\test\test_strptime.py", line 557, in test_main
    CacheTests
  File "C:\Python32\lib\test\support.py", line 1146, in run_unittest
    _run_suite(suite)
  File "C:\Python32\lib\test\support.py", line 1120, in _run_suite
    result = runner.run(suite)
  File "C:\Python32\lib\unittest\runner.py", line 173, in run
    result.printErrors()
  File "C:\Python32\lib\unittest\runner.py", line 110, in printErrors
    self.printErrorList('FAIL', self.failures)
  File "C:\Python32\lib\unittest\runner.py", line 117, in printErrorList
    self.stream.writeln("%s" % err)
  File "C:\Python32\lib\unittest\runner.py", line 25, in writeln
    self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in position 192:
 illegal multibyte sequence
2 tests failed:
    test_strptime test_time

----------
components: Windows
messages: 123612
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_time test_strptime fails on windows
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:03:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Dec 2010 15:03:01 +0000
Subject: [issue10649] Attempting to override special methods of a function
	object does not cause an error
In-Reply-To: <1291771835.4.0.575373997099.issue10649@psf.upfronthosting.co.za>
Message-ID: <1291820581.02.0.537323991215.issue10649@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oops, that second links has been renamed:
http://docs.python.org/dev/reference/datamodel#special-method-lookup

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10649>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:09:18 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:09:18 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1291820958.84.0.0864652731032.issue10652@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

test___all__ imports a lot of modules, but I found one of
following modules can bring same error.

# just import one of these in test_main(test___all__)

#    import idlelib.AutoComplete
#    import tkinter.scrolledtext
#    import tkinter.ttk
#    import turtle

//////////////////////////////////////////////////////

And actually, "import tkinter" is enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:19:03 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:19:03 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1291821543.61.0.375093027133.issue10652@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think this happens because 

1. test___all__.py imports tkinter module, and it
   imports tkinter/_fix.py
2. _fix.py sets TCL_LIBRARY etc as top level routine
3. regrtest.py resets os.environ after test___all__.py ends.
   so TCL_LIBRARY gone.
4. test_tcl.py tries to import tkinter module, but it won't
   be loaded twice, so TCL_LIBRARY won't be set.
5. tcl/tk cannot find its library

I think this can be fixed by save & restore sys.modules
before & after each tests, so that tkinter module can be
loaded again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:25:53 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:25:53 +0000
Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary)
In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za>
Message-ID: <1291821953.84.0.638006702316.issue10652@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

How about this patch? Is this kind of *fix* acceptable?

# I hope this works.

----------
keywords: +patch
Added file: http://bugs.python.org/file19977/py3k_restore_sys_modules_in_regrtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10652>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:37:32 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 15:37:32 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I'm not sure why this happens, I can see this on
official python3.2 beta1 windows binary.

C:\Python32>.\python -m test.regrtest test_datetime
[1/1] test_datetime
test test_datetime failed -- Traceback (most recent call last):
  File "c:\Python32\lib\test\datetimetester.py", line 1628, in test_computations

    self.assertRaises(TypeError, lambda: a+i)
AssertionError: TypeError not raised by <lambda>

1 test failed:
    test_datetime

----------
components: Library (Lib), Windows
messages: 123617
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_datetime fails on Python3.2 windows binary
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:40:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 08 Dec 2010 15:40:57 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291822857.53.0.643322900457.issue10653@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't see this on a US/English version of Windows 7 with 3.2b1 installed. cp932 is the default on a Japanese version, correct?

(I'm not very good with all of this encoding stuff so I don't know how much help I can be)

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 16:41:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 08 Dec 2010 15:41:19 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291822879.32.0.0672761503441.issue10654@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't see this on a US/English version of Windows 7 with 3.2b1 installed.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 17:21:57 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 08 Dec 2010 16:21:57 +0000
Subject: [issue1705520] API for excluding methods from unittest stack traces
Message-ID: <1291825317.86.0.948990989339.issue1705520@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

So from the stackframe you can only get to the code object not to the function object and although the code object is also reachable from a decorator it isn't mutable so we can't "mark it" in any way. We could in theory 're-build' the function and create a new code object (__code__ is assignable) by copying the original but adding a non-existent name to one of the code attributes. This is pretty horrible though.

So a *real* local variable (as suggested by Robert) would work, but the functionality wouldn't work on IronPython and would cause tools like pyflakes to complain about an unused name.

Another alternative is to use the docstring. This is available via code_object.co_consts[0], so we could use a marker in the docstring to indicate that this frame should be omitted from tracebacks. Unless we can make the marker either invisible (magic whitespace anyone?) or non-invasive this is also a not so pleasant idea. (And wouldn't work with -OO.)

Alternative suggestions welcomed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:33:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 17:33:02 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291829582.94.0.957565839166.issue10654@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/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:33:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 17:33:40 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291829620.43.0.641423378094.issue10653@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/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:39:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 17:39:34 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291829974.23.0.828130796547.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm still working on this, making sure the remaining options that aren't currently tested have tests and work.

----------
assignee: eric.araujo -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:43:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 17:43:42 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291830222.98.0.154845471232.issue10654@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Hirokazu,

Please rerun the test with a -v flag like this:

C:\Python32>.\python -m test.regrtest -v test_datetime

This should tell us whether the failure comes from C (Fast) implementation or Python (Pure) one.  The test in question simply tests that date(y, m, d) + 1 and datetime(y, m, d) + 1 raise TypeError.  Please see if you can reproduce the problem outside of the unit tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:46:29 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 17:46:29 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291830389.83.0.471441034195.issue10653@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think this is locale problem. With "C" locale on windows,
wcsftime doesn't return UTF16. (when non ascii characters
are contained)

It is just like ....
char cbuf[] = "...."; /* contains non ascii chars in MBCS */
wchar_t wbuf[sizeof(cbuf)];
for (size_t i = 0; i < sizeof(cbuf); ++i)
    wbuf[i] = cbuf[i];
/* just copy it. non ascii chars in MBCS uses two bytes,
   but should use 1 char space in UTF16. But this case,
   it uses 2 chars space! (something strange encoding) */

In japanese, wcsftime returns non ascii characters for
timezone in this strange encoding. Python converts this
with

#ifdef HAVE_WCSFTIME
            ret = PyUnicode_FromWideChar(outbuf, buflen);
#else

so Unicode object will contain data in this strange encoding.
This is cause of problem.

I investigated a little about locale, and I learned C
standard does not guarantee wchar_t is always UTF16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:57:09 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 17:57:09 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291831029.75.0.909919139576.issue10653@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'll attach workaround. I used to confirm this works on
VS8, but I don't have VS8 now. I hope this still works.

----------
keywords: +patch
Added file: http://bugs.python.org/file19978/py3k_workaround_for_wcsftime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 18:58:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 17:58:11 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291831091.28.0.453031146791.issue10653@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> ValueError: time data '2010 14 58 01 3 342 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)' does not match format '%Y %H %M %S %w %j %Z'

This looks like valid cp932 data to me
>>> b'2010 14 58 01 3 342 \x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)'.decode('cp932')
'2010 14 58 01 3 342 ?? (???)'

Please help me with Japanese, but I think the above means Tokyo timezone.  However, strftime should have produced decoded unicode strings, not raw cp932 in a str.  What does time.strftime('%Z') return on your system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:12:56 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 18:12:56 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291831976.26.0.826342276458.issue10653@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here you are.

>>> import time
>>> time.strftime('%Z')
'\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:16:04 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 18:16:04 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291832164.54.0.770455043205.issue10654@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

======================================================================
FAIL: test_computations (test.datetimetester.TestSubclassDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\Python32\lib\test\datetimetester.py", line 1628, in test_computations

    self.assertRaises(TypeError, lambda: a+i)
AssertionError: TypeError not raised by <lambda>

> Please see if you can reproduce the problem outside of the unit tests.

I'll try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:18:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 18:18:56 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291831976.26.0.826342276458.issue10653@psf.upfronthosting.co.za>
Message-ID: <AANLkTinOqpPCisnNVUVf97FH+LwxFwkgOkt5y_RK80K0@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 8, 2010 at 1:12 PM, Hirokazu Yamamoto
<report at bugs.python.org> wrote:
..
>>>> import time
>>>> time.strftime('%Z')
> '\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)'

Thanks.  Please bear with me for one more question:  what is

>>> time.tzname

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:33:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Dec 2010 18:33:58 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1291833238.82.0.601957850228.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The patch looks same to me as far as I can judge.
Thanks.  Can you apply the patch on your Windows machine and run the test suite?

> I would have used .format instead of %, but you wrote it ;-).
I would have too, were I writing Python :)  Here I tried to do the simplest thing that could work.

> Seeing how many of our tests had to be patched convinced me that we
> should treat this like a feature request and only apply to 3.2.
Yes, as an incompatible behaviour change I cannot go into released versions, as Brett stated in msg105994.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:42:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Dec 2010 18:42:28 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291833748.91.0.192083087327.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for stepping up.  I plead guilty too for letting bugs slip.  I?ll be here for pre- or post-commit review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:50:08 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 18:50:08 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291834208.86.0.726523010069.issue10653@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I got readable result. ;-)

>>> import time
>>> time.tzname
('?? (???)', '?? (???)')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:51:56 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 08 Dec 2010 18:51:56 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1291834316.56.0.821127842863.issue10644@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

>  it may be very convenient and the performance overhead may be barely noticeable.

Convenient for what ?
If the remote end doesn't send a FIN or RST packet, then the TCP/IP stack has no way of knowing the remote end is down.
Successfull return of send(2) never meant a succesfull delivery to the other end, see man page :
"No indication of failure to deliver is implicit in a send(). Locally detected errors are indicated by a return value of -1. "

If your remote application doesn't close its socket cleanly, then your application is broken.
To guard against that, you could use TCP keepalive...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Wed Dec  8 19:55:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Dec 2010 18:55:05 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291834505.46.0.628636559738.issue9517@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Having posted that it occurs to me that it could be useful to have the 
> _remove_refcount function in test.support

There's already strip_python_stderr() :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:14:33 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 08 Dec 2010 19:14:33 +0000
Subject: [issue1705520] API for excluding methods from unittest stack traces
Message-ID: <1291835673.43.0.238265208205.issue1705520@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Maybe a global registry... implemented with a WeakKeyDictionary?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:18:06 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 08 Dec 2010 19:18:06 +0000
Subject: [issue1705520] API for excluding methods from unittest stack traces
Message-ID: <1291835886.29.0.29953880511.issue1705520@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Global registry of code objects, hmmm... Could work. I'll prototype it and test it with IronPython / Jython / pypy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:21:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 19:21:42 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291836102.72.0.340931197912.issue10654@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This is shortest code to reproduce. But strange,
I can see TypeError on VC6(both Debug and Release)

E:\>e:\python-dev\py3k\pc\VC6\python.exe x.py
Traceback (most recent call last):
  File "x.py", line 10, in <module>
    a+i
TypeError: unsupported operand type(s) for +: 'SubclassDatetime' and 'int'

/////////////////////////////////////////////

from datetime import datetime

class SubclassDatetime(datetime):
    sub_var = 1

a = SubclassDatetime(2002, 3, 2, 17, 6)
# Add/sub ints or floats should be illegal
for i in 1, 1.0:
    a+i

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:29:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Dec 2010 19:29:31 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1291836571.01.0.607935843848.issue9517@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, good, I'll use that then.  I could have sworn I looked for that functionality a couple weeks ago and couldn't find it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:39:06 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 19:39:06 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291837146.33.0.50116627134.issue10654@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

By changing
  from datetime import datetime
to
  from _datetime import datetime
I can see same behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:45:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 19:45:38 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291834208.86.0.726523010069.issue10653@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=18uW+7mDK+Q7+1iMMt8EW+AqLkHjRip+wCvUM@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 8, 2010 at 1:50 PM, Hirokazu Yamamoto
<report at bugs.python.org> wrote:
..
> I got readable result. ;-)
>
You mean readable to *you*. :-)

>>>> import time
>>>> time.tzname
> ('?? (???)', '?? (???)')

This makes sense now.   There are two issues here:

1.  Decoding the output of wcsftime().  Python expects mbcs (which I
believe is an UTF16-like wide char encoding) while Windows apparently
puts cp932 there in your locale.  I don't have expertise to address
this issue.

2. strptime() cannot parse strftime() output when strftime('%Z') is
different from time.tzname[dst].  This issue we can address.  Note
that for most of the locale information such as day of the week or
month names, strptime() relies on strftime() output, so the
round-tripping should work even when strftime() results are
nonsensical.  On the other hand, tz spellings are taken from
time.tzname.    I think we can make strptime() more robust by adding
[time.strftime('%Z', (2000,1,1,0,0,0,0,0,dst) for dst in (0,1)] to the
list of recognized tz names if they differ from time.tzname.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Wed Dec  8 20:55:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 19:55:09 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291836102.72.0.340931197912.issue10654@psf.upfronthosting.co.za>
Message-ID: <AANLkTimMebtbnNbjAfx+2fjuWW7qNN2ABbqjXMMN588O@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 8, 2010 at 2:21 PM, Hirokazu Yamamoto
<report at bugs.python.org> wrote:
..
> /////////////////////////////////////////////
>
> from datetime import datetime
>
> class SubclassDatetime(datetime):
> ? ?sub_var = 1
>
> a = SubclassDatetime(2002, 3, 2, 17, 6)
> # Add/sub ints or floats should be illegal
> for i in 1, 1.0:
> ? ?a+i
>

What is the output here?  If you do this at the '>>>' prompt, you
should see the results, if you do it in a script, please add a
print().

Does this also happen with plain datetime or only a subclass?  What
about time, date, or their subclasses?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:11:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:11:48 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291839108.93.0.64270920079.issue10544@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#3267 did not expose endless loop possibility and was closed as won't fix.
Rather than reopen that and close this and move nosy list back, I added to nosy list here.

----------
nosy: +brett.cannon, erickt, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:12:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:12:02 +0000
Subject: [issue3267] yield in list comprehensions possibly broken in 3.0
In-Reply-To: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za>
Message-ID: <1291839122.19.0.0451514751213.issue3267@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
superseder:  -> yield expression inside generator expression does nothing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3267>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:24:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 20:24:37 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291839877.54.0.391882397594.issue10654@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

"NotImplementedError" was printed. This happened
when subclass of date or subclass of datetime.
(plain classes and subclass of time didn't print this)

////////////////////////////////////
// Code

from _datetime import date, datetime

class SubclassDate(date):
    sub_var = 1

a = SubclassDate(2002, 3, 2)
for i in 1, 1.0:
    print(a+i)  # "NotImplemented"

class SubclassDateTime(datetime):
    sub_var = 1

a = SubclassDateTime(2002, 3, 2, 3, 5)
for i in 1, 1.0:
    print(a+i)  # "NotImplemented"
a-i # TypeError: unsupported operand type(s) for -: 'SubclassDateTime' and 'float'

////////////////////////////////////
// Result

E:\python-dev\py3k>c:\Python32\python.exe \x.py
NotImplemented
NotImplemented
NotImplemented
NotImplemented
Traceback (most recent call last):
  File "\x.py", line 17, in <module>
    a-i # TypeError
TypeError: unsupported operand type(s) for -: 'SubclassDateTime' and 'float'

////////////////////////////////////////

I hope this helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:24:40 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:24:40 +0000
Subject: [issue7391] Re-title the "Using Backslash to Continue Statements"
	anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1291839880.34.0.466996932728.issue7391@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In #10545, 'rurpy2' gives a similar critique of this section and suggests that it be improved or removed. I agree that it needs change and will try to think of what would be better.

----------
nosy: +rurpy2, terry.reedy
versions:  -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:25:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:25:04 +0000
Subject: [issue10545] remove or rewrite "Using Backslash to Continue
	Statements" anti-idiom
In-Reply-To: <1290804632.88.0.494003444216.issue10545@psf.upfronthosting.co.za>
Message-ID: <1291839904.94.0.938818796969.issue10545@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is essentially a duplicate of #7391 where it is already agreed that a change should be made to that section.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Re-title the "Using Backslash to Continue Statements" anti-idiom

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10545>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:25:41 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 08 Dec 2010 20:25:41 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291839941.67.0.838541919119.issue10654@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, 
- "NotImplementedError" was printed
+ "NotImplemented" was printed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:27:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Dec 2010 20:27:02 +0000
Subject: [issue7391] Re-title the "Using Backslash to Continue Statements"
	anti-idiom
In-Reply-To: <1259072363.61.0.346322429524.issue7391@psf.upfronthosting.co.za>
Message-ID: <1291840022.23.0.407518851084.issue7391@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll take that section out.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7391>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:34:15 2010
From: report at bugs.python.org (Mark Florisson)
Date: Wed, 08 Dec 2010 20:34:15 +0000
Subject: [issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1291840455.87.0.66027468757.issue10566@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

Indeed, I'm trying to make the code Python 2 and Python 3 (for the inferior) compatible, it's not really hard but indeed, the 'u' (Python 2) and 'b' (Python 3) stuff need special casing. Python 2 compatibility was also the reason why the PyIntObjectPtr class was merged back. I will make a patch that's compatible with both Python 2 and 3 (and without any "colorful" code :)) as this would be most preferably I think (even if it's shipped with Python 3, users might still want to use it for Python 2, and it's also easier for the Cython debugger which wants to be compatible with 2.5+).

As for the gdb version, I have tested with 7.1 (in which case the introduced commands won't work as they use stuff from the 7.2 API, in which case test_gdb.py also skips those tests) and 7.2. I agree that the functionality should be left out if it cannot work properly.

Indeed, the _LoggingState redirects logging to a file and then reads the output after the command returns, I've been using it successfully with big amounts of output and I don't think there should be a problem as redirection and pagination should be unrelated. The good thing about _LoggingState is that it actually captures *all* output (and it's fully reentrant), which the 'to_string' argument was not taking care of properly in 7.2 (it's fixed in the archer branch).

Indeed, gdb.get_selected_thread() is entirely broken in 7.2 (again, fixed in archer) but as you can see, it's not used (gdb.inferiors()[0] "works").

I'm currently looking into making stepping over faster and by extension stepping which we discussed earlier (I also discussed it with Tom Tromey previously). As you know, currently stepping over (and stepping) works with a "step-over loop" which might be turned into a "set a conditional breakpoint or watchpoint + continue" solution, which would mean a lot less context switches. I've not looked too serious into this matter, but I'll hope to get around to that soonish and I'll provide a new patch with all the corrections and improvements.
Another issue I'm fixing is the determination of the type of an arbitrary Python object, which was previously done with the Py_TPFLAGS_INT_SUBCLASS flags and friends. This is because they are new in 2.6 and I'd prefer to be 2.5 compatible (again, because I'm trying to keep the Cython debugger 2.5 compatible).

As for porting the gdb API to Python 3, I'm quite convinced that the API can be written in Cython, in which case it would mostly be a change in the build process rather than a serious code-refactoring issue. But I'll get around to that later...

Anyway, should I diff against the original libpython or against the original libpython + my previous diff?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:39:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 20:39:05 +0000
Subject: [issue10654] test_datetime fails on Python3.2 windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1291840745.7.0.0338525246955.issue10654@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> + "NotImplemented" was printed

Hmm, looks like a compiler bug to me.  Can anyone reproduce this on a debug build?  In any case, someone with a Windows setup will have to troubleshoot this further.

Note that the code in abstract.c is supposed to convert NotImplemented returns to type errors:

static PyObject *
binary_op(PyObject *v, PyObject *w, const int op_slot, const char *op_name)
{
    PyObject *result = binary_op1(v, w, op_slot);
    if (result == Py_NotImplemented) {
        Py_DECREF(result);
        return binop_type_error(v, w, op_name);
    }
    return result;
}

It should be possible to find out why this is not happening by stepping through this code with a debugger.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:40:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 08 Dec 2010 20:40:21 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291840821.76.0.649195070947.issue10544@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FWIW, the "endless loop possibility" is not of issue here, and is simply an artifact of the specific generator function the OP uses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:41:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:41:06 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291840866.6.0.995294025724.issue10546@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Marc or Alexander, can you confirm that the patch is correct?

----------
assignee: docs at python -> cgw
nosy: +belopolsky, cgw, lemburg, terry.reedy
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:57:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:57:07 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291841827.71.0.107897960616.issue10546@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: cgw -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 21:57:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:57:30 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291841850.12.0.167382923374.issue10546@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 22:48:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 21:48:17 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291844897.23.0.205752165721.issue10546@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

If Victor says so ...

Someone needs to check that it works on a UCS4 build, but on a narrow build I don't think UTF-16-XX encodings need to do anything special - they just encode the surrogates as ordinary code units.


>>> '\U00010000'.encode('UTF-16-BE').decode('UTF-16-BE') == '\U00010000'
True
>>> '\U00010000'.encode('UTF-16-LE').decode('UTF-16-LE') == '\U00010000'
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 22:50:27 2010
From: report at bugs.python.org (adrian)
Date: Wed, 08 Dec 2010 21:50:27 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>


New submission from adrian <adrian at lisas.de>:

In Python/ceval.c is following line:

#if defined(__ppc__) /* <- Don't know if this is the correct symbol; this
                           section should work for GCC on any PowerPC
                           platform, irrespective of OS.
                           POWER?  Who knows :-) */

which seems wrong and aborts the build on powerpc. Changing it to __powerpc__ fixes it for me.

The following output of gcc confirms it:

$ gcc -dM -E -x c /tmp/foo.c  | grep powerpc
#define __powerpc__ 1
#define __powerpc 1
#define powerpc 1

Whereas there are no defines containing "ppc"

----------
components: Build
messages: 123652
nosy: adrian
priority: normal
severity: normal
status: open
title: Wrong powerpc define in Python/ceval.c
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Wed Dec  8 22:57:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Dec 2010 21:57:43 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291845463.2.0.172618066811.issue10655@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How about accepting either of these symbols? Do you want to provide a patch?

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:04:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 22:04:13 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291845853.98.0.131129667867.issue10546@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have verified that UTF-16-XX encodings work on wide build.  The doc change LGTM.  Bonus points for checking that we have unit tests for these encodings that include non-BMP characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:05:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 22:05:50 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291845950.14.0.568688354018.issue10546@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:08:34 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 22:08:34 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1291846114.47.0.869837071226.issue9738@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

A (probably crazy) idea that just occurred to me:
  typedef char utf8_bytes;
  typedef char iso8859_1_bytes;
  typedef char fsenc_bytes;

then specify the encoding in the type signature of the API e.g.:
- int PyRun_SimpleFile(FILE *fp, const char *filename)
+ int PyRun_SimpleFile(FILE *fp, const fsenc_bytes *filename)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:13:25 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 22:13:25 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291846405.91.0.511500607556.issue10655@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

What version of the compiler was this with?

(For reference, I see that you also filed this downstream in Fedora's bug tracker as:
 https://bugzilla.redhat.com/show_bug.cgi?id=661510 )

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:26:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Dec 2010 22:26:35 +0000
Subject: [issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291847195.17.0.286348078618.issue10546@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r87135.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:40:28 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 22:40:28 +0000
Subject: [issue9518] PyModuleDef_HEAD_INIT does not explicitly initialize all
	fields of m_base
In-Reply-To: <1280965412.21.0.0751804906986.issue9518@psf.upfronthosting.co.za>
Message-ID: <1291848028.97.0.593136605934.issue9518@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Forgot to close this one out

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:40:49 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 22:40:49 +0000
Subject: [issue9518] PyModuleDef_HEAD_INIT does not explicitly initialize all
	fields of m_base
In-Reply-To: <1280965412.21.0.0751804906986.issue9518@psf.upfronthosting.co.za>
Message-ID: <1291848049.23.0.911461103159.issue9518@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:42:03 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 22:42:03 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1291848123.69.0.328423847144.issue10399@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
assignee:  -> dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Wed Dec  8 23:55:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 22:55:11 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1291848911.44.0.756446519525.issue9738@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> A (probably crazy) idea that just occurred to me:
>  typedef char utf8_bytes;
>  typedef char iso8859_1_bytes;
>  typedef char fsenc_bytes;

I like it!  Let's see how far we can get without iso8859_1_bytes, though.  (It is likely to be locale_bytes anyways.)  There are a few places where we'll need ascii_bytes.

The added benefit is that we can make these typedefs unsigned char and avoid char signness being ambiguous.  We will also need to give the typedefs the Py_ prefix.

And an obligatory bikesheding comment: if we typedef char, we should use singular form.  Or we can typedef char* Py_utf8_bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Thu Dec  9 00:06:58 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 23:06:58 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291849618.34.0.362744546681.issue10655@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

One of RH's gcc gurus told me in IRC that:
  __ppc__ is not a standard powerpc*-linux macro
  __PPC__ or __powerpc__ is

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Dec  9 00:23:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Dec 2010 23:23:56 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291849618.34.0.362744546681.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291850632.3648.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 08 d?cembre 2010 ? 23:06 +0000, Dave Malcolm a ?crit :
> Dave Malcolm <dmalcolm at redhat.com> added the comment:
> 
> One of RH's gcc gurus told me in IRC that:
>   __ppc__ is not a standard powerpc*-linux macro
>   __PPC__ or __powerpc__ is

Keep in mind that we have currently working PPC buildbots (under OS X).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Dec  9 00:33:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 23:33:45 +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: <1291851225.07.0.191831219766.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed revision 87137.  Needs backporting.  Also as Victor suggested, _lsprof.c code can be refactored to avoid roundtrips of unicode through utf8 char*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Dec  9 01:01:41 2010
From: report at bugs.python.org (Brian Cain)
Date: Thu, 09 Dec 2010 00:01:41 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1291852901.9.0.891078333917.issue8426@psf.upfronthosting.co.za>


Brian Cain <brian.cain at gmail.com> added the comment:

I don't think the problem is limited to when hundreds of megabytes are being transmitted.  I believe I am experiencing a problem with the same root cause whose symptoms are slightly different.  It seems like there's a threshhold which causes not merely poor performance, but likely an unrecoverable fault.

Here's the output when I run my example on SLES11.1:

$ ./multiproc.py $((8*1024)) 2
on 2.6 (r26:66714, May  5 2010, 14:02:39) 
[GCC 4.3.4 [gcc-4_3-branch revision 152973]] - Linux linux 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 x86_64 x86_64
0 entries in flight, join() took 5949.97 usec, get() did 0.000000 items/sec
2 entries in flight, join() took 1577.85 usec, get() did 42581.766497 items/sec
4 entries in flight, join() took 1966.00 usec, get() did 65536.000000 items/sec
6 entries in flight, join() took 1894.00 usec, get() did 105296.334728 items/sec
8 entries in flight, join() took 1420.02 usec, get() did 199728.761905 items/sec
10 entries in flight, join() took 1950.03 usec, get() did 163840.000000 items/sec
12 entries in flight, join() took 1241.92 usec, get() did 324720.309677 items/sec
...
7272 entries in flight, join() took 2516.03 usec, get() did 10983427.687432 items/sec
7274 entries in flight, join() took 1813.17 usec, get() did 10480717.037444 items/sec
7276 entries in flight, join() took 1979.11 usec, get() did 11421315.832335 items/sec
7278 entries in flight, join() took 2043.01 usec, get() did 11549808.744608 items/sec
^C7280 entries: join() ABORTED by user after 83.08 sec
...

I see similar results when I run this test with a larger step, I just wanted to get finer resolution on the failure point.

----------
nosy: +Brian.Cain
versions: +Python 2.6
Added file: http://bugs.python.org/file19979/multiproc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Dec  9 01:13:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 00:13:33 +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: <1291853613.64.0.989532200515.issue6697@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching an untested rewrite of normalizeUserObj() in _lsprof.c for comments on whether it is worth the effort.  There might be other places where PyModule_GetName() can be profitably replaced with PyModule_GetNameObject().

----------
Added file: http://bugs.python.org/file19980/issue6697-lsprof.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Dec  9 01:55:24 2010
From: report at bugs.python.org (Daniel Tavares)
Date: Thu, 09 Dec 2010 00:55:24 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1291856124.25.0.380748838847.issue10367@psf.upfronthosting.co.za>


Daniel Tavares <danielmtavares at gmail.com> added the comment:

Here goes the test. Feel free to make any comments, critiques or suggestions, since this is my first take on this code base.

----------
versions:  -3rd party
Added file: http://bugs.python.org/file19981/test_10367.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Thu Dec  9 03:28:16 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Dec 2010 02:28:16 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1291861696.53.0.562883379193.issue8426@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6.6 was the last bugfix release

----------
type: crash -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Dec  9 03:34:35 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 09 Dec 2010 02:34:35 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1291862075.55.0.508358853291.issue10154@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

Ubuntu 10.4.1 LTS 
 also work fine with both "UTF8" and "UTF-8"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Dec  9 04:35:04 2010
From: report at bugs.python.org (Perry Smith)
Date: Thu, 09 Dec 2010 03:35:04 +0000
Subject: [issue10656] "Out of tree" build fails on AIX 5.3
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>


New submission from Perry Smith <pedzsan at gmail.com>:

I do "out of tree" builds (I think that is the right term).  I make an
empty directory, cd into it, and then do: 

<path to src directory>/configure

followed by make.  This works on most open source pages.  It appears to
be very close to working with Python 2.7.1 but the problem is that it assumes ld_so_aix is in the source tree but it is in the build tree.

I did an "in tree" build using basically just ./configure && make and so far (I'm still testing) that has worked fine.

----------
components: Build
messages: 123668
nosy: pedz
priority: normal
severity: normal
status: open
title: "Out of tree" build fails on AIX 5.3
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10656>
_______________________________________

From report at bugs.python.org  Thu Dec  9 04:36:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Dec 2010 03:36:00 +0000
Subject: [issue10656] "Out of tree" build fails on AIX 5.3
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1291865760.46.0.0218698944181.issue10656@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10656>
_______________________________________

From report at bugs.python.org  Thu Dec  9 06:45:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 05:45:46 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1291873546.61.0.0777346114573.issue1706039@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The tests need to be cleaned up a little.  The setup code should go to setUp() method and instead of calling different methods in a loop with a switch over method names, it should just have a separate test_ method for each method tested.  A "with" statement can also reduce some boilerplate.

----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706039>
_______________________________________

From report at bugs.python.org  Thu Dec  9 06:46:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Dec 2010 05:46:19 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1291873579.29.0.0234386627466.issue1353344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Apart from the desktop file itself, which should be a merged version of the last attachment to this report and the files in Debuntu/Fedora/whatever, there is the issue of installation.  Someone has to track the desktop file spec or menu spec and edit one of the files involved in the Python build process.

I don?t know if having missed beta1 means that this will be deferred to 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353344>
_______________________________________

From report at bugs.python.org  Thu Dec  9 06:46:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Dec 2010 05:46:47 +0000
Subject: [issue1745761] Bad attributes/data handling in SGMLib
Message-ID: <1291873607.65.0.769059191899.issue1745761@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, r.david.murray -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745761>
_______________________________________

From report at bugs.python.org  Thu Dec  9 07:16:44 2010
From: report at bugs.python.org (Brian Cain)
Date: Thu, 09 Dec 2010 06:16:44 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1291875404.07.0.193140723497.issue8426@psf.upfronthosting.co.za>


Brian Cain <brian.cain at gmail.com> added the comment:

I was able to reproduce the problem on a more recent release.

7279 entries fails, 7278 entries succeeds.


$ ./multiproc3.py 
on 3.1.2 (r312:79147, Apr 15 2010, 12:35:07) 
[GCC 4.4.3] - Linux mini 2.6.32-26-generic #47-Ubuntu SMP Wed Nov 17 15:59:05 UTC 2010 i686 
7278 entries in flight, join() took 12517.93 usec, get() did 413756.736588 items/sec
7278 entries in flight, join() took 19458.06 usec, get() did 345568.562217 items/sec
7278 entries in flight, join() took 21326.07 usec, get() did 382006.563784 items/sec
7278 entries in flight, join() took 14937.16 usec, get() did 404244.835554 items/sec
7278 entries in flight, join() took 18877.98 usec, get() did 354435.878968 items/sec
7278 entries in flight, join() took 20811.08 usec, get() did 408343.738456 items/sec
7278 entries in flight, join() took 14394.04 usec, get() did 423727.055218 items/sec
7278 entries in flight, join() took 18940.21 usec, get() did 361012.624762 items/sec
7278 entries in flight, join() took 19073.96 usec, get() did 367559.024118 items/sec
7278 entries in flight, join() took 16229.87 usec, get() did 424764.763755 items/sec
7278 entries in flight, join() took 18527.03 usec, get() did 355546.367937 items/sec
7278 entries in flight, join() took 21500.11 usec, get() did 390429.802164 items/sec
7278 entries in flight, join() took 13646.84 usec, get() did 410468.669903 items/sec
7278 entries in flight, join() took 18921.14 usec, get() did 355873.819767 items/sec
7278 entries in flight, join() took 13582.94 usec, get() did 287553.877353 items/sec
7278 entries in flight, join() took 21958.11 usec, get() did 405549.873285 items/sec
^C7279 entries: join() ABORTED by user after 5.54 sec
^CError in atexit._run_exitfuncs:
Segmentation fault

----------
Added file: http://bugs.python.org/file19982/multiproc3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Dec  9 07:18:37 2010
From: report at bugs.python.org (Brian Cain)
Date: Thu, 09 Dec 2010 06:18:37 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1291875517.54.0.199223197046.issue8426@psf.upfronthosting.co.za>


Brian Cain <brian.cain at gmail.com> added the comment:

Detailed stack trace when the failure occurs (gdb_stack_trace.txt)

----------
Added file: http://bugs.python.org/file19983/gdb_stack_trace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Dec  9 09:28:34 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Dec 2010 08:28:34 +0000
Subject: [issue10657] os.lstat/os.stat/os.fstat don't set st_dev (st_rdev) on
	Windows
In-Reply-To: <1291883314.59.0.723924565761.issue10657@psf.upfronthosting.co.za>
Message-ID: <1291883314.59.0.723924565761.issue10657@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed st_dev is not set yet. Attached patch
fill this value, but sometimes it becomes negative
value because dwVolumeSerialNumber is large enough.
Maybe st_dev should be declared as unsigned int.

# I think this is not new feature. Just bug. So I think
# this can go into python3.2.

----------
components: Windows
files: py3k_add_st_dev_and_st_rdev.patch
keywords: patch
messages: 123673
nosy: ocean-city
priority: normal
severity: normal
status: open
title: os.lstat/os.stat/os.fstat don't set st_dev (st_rdev) on Windows
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19984/py3k_add_st_dev_and_st_rdev.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10657>
_______________________________________

From report at bugs.python.org  Thu Dec  9 09:56:41 2010
From: report at bugs.python.org (=?utf-8?q?Anders_Chrigstr=C3=B6m?=)
Date: Thu, 09 Dec 2010 08:56:41 +0000
Subject: [issue1571170] Some numeric characters are still not recognized
Message-ID: <1291885001.27.0.580973690166.issue1571170@psf.upfronthosting.co.za>


Anders Chrigstr?m <andersch at users.sourceforge.net> added the comment:

This is indeed a duplicate of #1571184

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571170>
_______________________________________

From report at bugs.python.org  Thu Dec  9 11:47:32 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Dec 2010 10:47:32 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1291891652.83.0.972924024636.issue9927@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This is updated version. Can you test this?
(I only fixed leak, deferred other fixes to future)

----------
Added file: http://bugs.python.org/file19985/py3k_fix_leak_around_GetFinalPathNameByHandle_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Dec  9 11:47:53 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Dec 2010 10:47:53 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1291891673.43.0.438384096536.issue9927@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file18979/py3k_fix_leak_around_GetFinalPathNameByHandle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Dec  9 11:54:40 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Dec 2010 10:54:40 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1291892080.25.0.598883773091.issue10653@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> 1.  Decoding the output of wcsftime().  Python expects mbcs (which
> I believe is an UTF16-like wide char encoding) while Windows
> apparently puts cp932 there in your locale.  I don't have expertise
> to address this issue.

No, mbcs is not wide character sets (wchar_t*) but ANSI character sets
(char*). In my environment, mbcs == cp932. And python expects UTF-16. 

> 2. strptime() cannot parse strftime() output when strftime('%Z') is
> different from time.tzname[dst]. (snip)

I attached test program to test behavior of strftime and wcsftime
on locale. On VC6, strftime doesn't depend on locale, wheres
wcsftime changed the value depends on locale. (I tested only "C"
locale and "System" locale because I could not find other
locales working on my environment, so )

If strftime doesn't depend on locale and equals to tzname
for every locale, maybe strftime is preferred on windows.

# Can somebody test this on VS9? And other locales?

----------
Added file: http://bugs.python.org/file19986/main.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10653>
_______________________________________

From report at bugs.python.org  Thu Dec  9 13:11:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Dec 2010 12:11:29 +0000
Subject: [issue10658] Link to source code is broken
In-Reply-To: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>
Message-ID: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/queue.html

----------
assignee: docs at python
components: Documentation
messages: 123677
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Link to source code is broken
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10658>
_______________________________________

From report at bugs.python.org  Thu Dec  9 13:13:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 12:13:49 +0000
Subject: [issue10658] Link to source code is broken
In-Reply-To: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>
Message-ID: <1291896829.94.0.421601720399.issue10658@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87143.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10658>
_______________________________________

From report at bugs.python.org  Thu Dec  9 13:48:36 2010
From: report at bugs.python.org (adrian)
Date: Thu, 09 Dec 2010 12:48:36 +0000
Subject: [issue10655] Wrong powerpc define in Python/ceval.c
In-Reply-To: <1291845027.1.0.195055674772.issue10655@psf.upfronthosting.co.za>
Message-ID: <1291898916.38.0.132332831227.issue10655@psf.upfronthosting.co.za>


adrian <adrian at lisas.de> added the comment:

Here is a patch that I had to include in my Linux PowerPC build of 2.7 and 3.2

--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -31,10 +31,12 @@
 
 typedef unsigned long long uint64;
 
-#if defined(__ppc__) /* <- Don't know if this is the correct symbol; this
+#if defined(__ppc__) || defined (__powerpc__) /* <- Don't know if 
+                           this is the correct symbol; this
                            section should work for GCC on any PowerPC
                            platform, irrespective of OS.
-                           POWER?  Who knows :-) */
+                           POWER?  Who knows :-) 
+                           __powerpc__ is necessary for Linux */
 
 #define READ_TIMESTAMP(var) ppc_getcounter(&var)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10655>
_______________________________________

From report at bugs.python.org  Thu Dec  9 14:20:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Dec 2010 13:20:33 +0000
Subject: [issue10659] Hook scripts for immediate doc build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

When a new revision is committed to documentation, it will be nice to have hook scripts that start documentation build process on development server. 

Another hook script may also analyze commit message, extract ticket number, branch and revision from it. Then post a comment with a link to development version of documentation and close the ticket.

See how it works on Google Code http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control

----------
assignee: docs at python
components: Documentation
messages: 123680
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Hook scripts for immediate doc build system

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10659>
_______________________________________

From report at bugs.python.org  Thu Dec  9 14:56:46 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 09 Dec 2010 13:56:46 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1291903006.58.0.819509769148.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Here is the updated patch, which fixed:

1. remove get() method of gdbm since issue6045 has already add it.

2. method keys() and items() of dbm object return set instead of list. Since pep3119 said keys() and items() should return collections.Set and set is a collections.Set.

3. add update() method to dbm object, which follows implementation in collections.MutableMapping.update().

----------
Added file: http://bugs.python.org/file19987/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Thu Dec  9 15:22:57 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 09 Dec 2010 14:22:57 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291904577.61.0.563861017702.issue10516@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

eli, you should also add "New in version 3.3" to the doc of the tow new list methods.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Dec  9 15:49:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 14:49:15 +0000
Subject: [issue10659] Hook scripts for immediate doc build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1291906155.79.0.0807608625741.issue10659@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The development docs are rebuilt twice a day; that should be enough.

As for tracker integration with version control, that is already an issue for the meta tracker at http://psf.upfronthosting.co.za/roundup/meta/issue20 (which you should know, since you commented there.)

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10659>
_______________________________________

From report at bugs.python.org  Thu Dec  9 16:33:43 2010
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Cauwelier?=)
Date: Thu, 09 Dec 2010 15:33:43 +0000
Subject: [issue10660] format() to lower and uppercase
In-Reply-To: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>
Message-ID: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>


New submission from Herv? Cauwelier <herve at itaapy.com>:

Hexadecimals can be formatted to lower and uppercase:

>>> '{0:x}'.format(123)
'7b'
>>> '{0:X}'.format(123)
'7B'

I would like the same thing for strings:

>>> '{0.lastname:u} {0.firstname}'.format(user)
'DOE John'

I first thought using "S" for uppercase, but "s" is not available for lowercase. So I thought about "u" and "l".

The alternative is to write:

>>> '{0} {1}'.format(user.lastname.upper(), user.firstname)
'DOE John'

But I find it less compact and elegant.

----------
components: Interpreter Core
messages: 123684
nosy: Herv? Cauwelier
priority: normal
severity: normal
status: open
title: format() to lower and uppercase
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10660>
_______________________________________

From report at bugs.python.org  Thu Dec  9 16:53:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Dec 2010 15:53:26 +0000
Subject: [issue10660] format() to lower and uppercase
In-Reply-To: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>
Message-ID: <1291910006.72.0.486069571983.issue10660@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The format support is written specifically so that it is extensible.  You can write your own string subclass that extends the formatting mini-language with whatever features you find useful.  There are too many variations on what might be useful with regards to case transformations for this to be a sensible addition to the language itself.  Much better that an application create use-case tailored facilities.

(Note, by the way, that new features can only go in to 3.3 at this point.)

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10660>
_______________________________________

From report at bugs.python.org  Thu Dec  9 16:55:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Dec 2010 15:55:41 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1291910141.31.0.26863637985.issue6422@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Thu Dec  9 17:53:53 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 09 Dec 2010 16:53:53 +0000
Subject: [issue10660] format() to lower and uppercase
In-Reply-To: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>
Message-ID: <1291913633.78.0.620278175237.issue10660@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with David.

Here's an example of using such a subclass. It extends the format string for strings to begin with an optional 'u' or 'l':
-----------------------
class U(str):
    def __format__(self, fmt):
        if fmt[0] == 'u':
            s = self.upper()
            fmt = fmt[1:]
        elif fmt[0] == 'l':
            s = self.lower()
            fmt = fmt[1:]
        else:
            s = str(self)
        return s.__format__(fmt)

name = 'Herv? Cauwelier'

print('{0:u*^20} {0:l*^20} {0:*^20}'.format(U(name)))
-----------------------

It produces:
**HERV? CAUWELIER*** **herv? cauwelier*** **Herv? Cauwelier***

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10660>
_______________________________________

From report at bugs.python.org  Thu Dec  9 17:54:10 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 09 Dec 2010 16:54:10 +0000
Subject: [issue10661] ElementTree QName has a very uninformative repr()
In-Reply-To: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>
Message-ID: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

This is somewhat unfortunate behavior:

>>> from xml.etree.ElementTree import QName
>>> QName('foo')
<xml.etree.ElementTree.QName instance at 0x10049c830>
>>> 

It becomes even more apparent when encountered in a situation like this:

>>> print {QName('foo'): 'bar', QName('baz'): 'quux'}
{<xml.etree.ElementTree.QName instance at 0x10049cb90>: 'bar', <xml.etree.ElementTree.QName instance at 0x10049c248>: 'quux'}
>>> 

I would like to see QName.__repr__ return something like '<QName %r>' % (text,)

----------
messages: 123687
nosy: exarkun
priority: normal
severity: normal
status: open
title: ElementTree QName has a very uninformative repr()
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10661>
_______________________________________

From report at bugs.python.org  Thu Dec  9 18:53:56 2010
From: report at bugs.python.org (Christian Oudard)
Date: Thu, 09 Dec 2010 17:53:56 +0000
Subject: [issue10662] Typo in concurrent.futures, "seperate"
In-Reply-To: <1291917236.85.0.349427254238.issue10662@psf.upfronthosting.co.za>
Message-ID: <1291917236.85.0.349427254238.issue10662@psf.upfronthosting.co.za>


New submission from Christian Oudard <christian.oudard at gmail.com>:

Found the misspelling "seperate" in two places in the concurrent.futures library module.

Patch attached, correcting the spelling to "separate".

----------
files: seperate.patch
keywords: patch
messages: 123688
nosy: Christian.Oudard
priority: normal
severity: normal
status: open
title: Typo in concurrent.futures, "seperate"
versions: Python 3.2
Added file: http://bugs.python.org/file19988/seperate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10662>
_______________________________________

From report at bugs.python.org  Thu Dec  9 19:08:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 18:08:53 +0000
Subject: [issue10662] Typo in concurrent.futures, "seperate"
In-Reply-To: <1291917236.85.0.349427254238.issue10662@psf.upfronthosting.co.za>
Message-ID: <1291918133.92.0.0521727290339.issue10662@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87146.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10662>
_______________________________________

From report at bugs.python.org  Thu Dec  9 19:10:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 18:10:45 +0000
Subject: [issue10661] ElementTree QName has a very uninformative repr()
In-Reply-To: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>
Message-ID: <1291918245.76.0.830577162337.issue10661@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r87147.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10661>
_______________________________________

From report at bugs.python.org  Thu Dec  9 19:22:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 09 Dec 2010 18:22:42 +0000
Subject: [issue10661] ElementTree QName has a very uninformative repr()
In-Reply-To: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>
Message-ID: <1291918962.3.0.658344183014.issue10661@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This should be either:
'<QName %r>' % (self.text,)
or:
'<QName {!r}>'.format(self.text)

If self.text is a tuple (which granted is its own error), then the version checked in will raise an exception.

----------
nosy: +eric.smith
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10661>
_______________________________________

From report at bugs.python.org  Thu Dec  9 19:26:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 18:26:35 +0000
Subject: [issue10661] ElementTree QName has a very uninformative repr()
In-Reply-To: <1291913650.88.0.227621889863.issue10661@psf.upfronthosting.co.za>
Message-ID: <1291919195.28.0.169641425065.issue10661@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Granted.  Since the rest of the file uses old-style format, I've kept to it, r87148.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10661>
_______________________________________

From report at bugs.python.org  Thu Dec  9 19:43:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 18:43:38 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1291920218.47.0.913429999027.issue7475@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With Georg's approval, I am reopening this issue until a decision is made on whether {str,bytes,bytearray}.{transform,untransform} methods should go into 3.2.

I am adding Guido to "nosy" because the decision may turn on the interpretation of his post. [1]

I also started a python-dev thread on this issue. [2]

[1] http://mail.python.org/pipermail/python-dev/2010-December/106374.html
[2] http://mail.python.org/pipermail/python-dev/2010-December/106617.html

----------
components: +Unicode
nosy: +gvanrossum
resolution: fixed -> 
stage:  -> commit review
status: closed -> open
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Thu Dec  9 19:45:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Dec 2010 18:45:26 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1291920326.66.0.187085677522.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, here is what I hope is a comprehensive set of CLI tests, and fixes for the bugs revealed thereby.  Except for the new test added by Georg after the original patch here was committed, all of the tests either pass using the old compileall module or fail only because stderr has resource warnings in it.

I did some refactoring on the tests, and since there were few enough original tests I went through and refactored them all.  Hopefully that won't make the review more difficult.

Note that I have not tested this patch on windows :)

----------
Added file: http://bugs.python.org/file19989/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Thu Dec  9 20:25:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Dec 2010 19:25:31 +0000
Subject: [issue10663] configure shouldn't set a default OPT
In-Reply-To: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>
Message-ID: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The configure.in sets a default OPT of "-O" if none was set by the user, but I think that's wrong. The user could simply pass optimization flags as part of CFLAGS instead, and then the contents of OPT could conflict with that of CFLAGS (which is annoying to debug when you don't know what is happening exactly).

Besides, "-O" is hardly an useful default value for any compiler. I would advocate trimming down the magic and letting OPT empty/undefined if that's what the user asks for (and expects). What do you think?

----------
components: Build
messages: 123695
nosy: barry, dmalcolm, laca, pitrou
priority: normal
severity: normal
status: open
title: configure shouldn't set a default OPT
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10663>
_______________________________________

From report at bugs.python.org  Thu Dec  9 21:49:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Dec 2010 20:49:09 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291927749.24.0.52550017954.issue5845@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

for what it is worth, I am +1 on having completion and history file work by default.  The sqlite3 command line does this, for example.  I think it is what unix user expect nowadays, and I think it is reasonable.

Looking at my home directory, it would appear that the de-facto standard history file name would be .python_history.  This is based on .mysql_history, .psql_history, and .sqlite_history, none of which I configured explicitly to support history saving.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 21:54:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Dec 2010 20:54:54 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291928094.92.0.15928575499.issue5845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, that?s one question answered.  Still to solve: How to bind the right key? (?But perhaps tab isn?t the right key to bind. I think inputrc could set it to something different, perhaps shell rc files too. Is there an API to get this setting, does readline.so already do the right thing, or does it have to be added??)

----------
versions: +Python 3.3 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 21:59:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Dec 2010 20:59:00 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291928340.72.0.463506639185.issue5845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think TAB is the key expected by most people, so let's make it the default.
As for the location, site.py is an adequate one IMO.

----------
components: +Library (Lib) -Interpreter Core
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:11:02 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 09 Dec 2010 21:11:02 +0000
Subject: [issue10664] xml.sax.expatreader should support namespace prefixes
In-Reply-To: <1291929062.2.0.554979073686.issue10664@psf.upfronthosting.co.za>
Message-ID: <1291929062.2.0.554979073686.issue10664@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

The xml.sax.expatreader module pre-dates prefix reporting from Expat, and should be modified to support the feature_namespace_prefixes feature instead of complaining that Expat doesn't support prefixes.

----------
assignee: fdrake
components: XML
messages: 123699
nosy: fdrake
priority: normal
severity: normal
stage: needs patch
status: open
title: xml.sax.expatreader should support namespace prefixes
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10664>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:31:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 21:31:16 +0000
Subject: [issue10665] Update and expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

unicodedata module documentation has not been updated to reflect transition to 6.0.  Attached patch fixes the version and unicode.org links and starts making the documentation rely less on the unicode.org pages for basic understanding of the provided functionality.

I am posting work in progress to solicit feedback on how much of the Unicode Standard information we would want to present here.

On of the goals of this patch is to provide a standard reference that can be used throughout the library manual for basic Unicode concepts without sending the reader over to unicode.org.

----------
assignee: docs at python
components: Documentation
files: unicodedata-doc.diff
keywords: patch
messages: 123700
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Update and expand unicodedata module documentation
versions: Python 3.2
Added file: http://bugs.python.org/file19990/unicodedata-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:34:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 21:34:32 +0000
Subject: [issue10665] Update and expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291930472.16.0.773767903898.issue10665@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:44:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Dec 2010 21:44:26 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

32-bit-only OS X installers build and link to a copy of the GNU readline library for use by the readline module in the standard library.  But, the newer 64-bit/32-bit installer variants for 2.7 and 3.2 link to the OS X supplied BSD editline (libedit) library using its GNU readline compatibility interface.  This creates a confusing situation for users: depending on which installer variant is used for 2.7 or 3.2, the commands needed to enable things like tab completion.

Here's a snippet of what I have in my startup file:

    import readline
    import rlcompleter
    if 'libedit' in readline.__doc__:
        readline.parse_and_bind("bind ^I rl_complete")
    else:
        readline.parse_and_bind("tab: complete")

While obviously this can be handled, it seems like an unnecessary burden on users.  I think the primary reason for adding the editline support was to make it simpler for developers building their own Pythons.  That's not a concern for the installer build.  Another concern may have been to avoid shipping a copy of GNU readline which is GPL-licensed.  (The installer currently, to the best of my knowledge, does not document in a README or elsewhere that GNU readline is included.)  That seems a problem.  This disparity also could cause problems elsewhere (see Issue5845).

I see two solutions:

1. (trivial) Change the installer to always build and include GNU readline regardless of SDK (today, editline is used with builds using SDK 10.5 or higher).  

2. (TBD) Build and link with the open-source version of editline for all installers.

In either case, the installer should include license info on included 3rd-party libraries somewhere in the installer README and/or installed files.

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 123701
nosy: ned.deily, ronaldoussoren
priority: high
severity: normal
stage: needs patch
status: open
title: OS X installer variants have confusing readline differences
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:47:25 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Dec 2010 21:47:25 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291931245.9.0.322047925348.issue5845@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Keep in bind that there the Python readline module may be linked to either GNU readline or the BSD editline (libedit) library and they have different command strings.  Note the warning here:

http://docs.python.org/dev/py3k/library/readline.html

Here's a snippet of what I have today in my startup file:

    import rlcompleter
    if 'libedit' in readline.__doc__:
        readline.parse_and_bind("bind ^I rl_complete")
    else:
        readline.parse_and_bind("tab: complete")

See Issue10666 for more details and some possible changes.

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:48:11 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Dec 2010 21:48:11 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291931291.26.0.168176161881.issue5845@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Keep in mind that the Python readline module may be linked to either GNU readline or the BSD editline (libedit) library and they have different command strings.  Note the warning here:

http://docs.python.org/dev/py3k/library/readline.html

Here's a snippet of what I have today in my startup file:

    import rlcompleter
    if 'libedit' in readline.__doc__:
        readline.parse_and_bind("bind ^I rl_complete")
    else:
        readline.parse_and_bind("tab: complete")

See Issue10666 for more details and some possible changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 22:48:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Dec 2010 21:48:17 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291931297.98.0.289008122794.issue5845@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg123702

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 23:27:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 22:27:02 +0000
Subject: [issue10665] Update and expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291933622.69.0.226915907811.issue10665@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Added more tables semi-automatically produced from http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt

----------
Added file: http://bugs.python.org/file19991/unicodedata-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Thu Dec  9 23:27:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 22:27:07 +0000
Subject: [issue10665] Update and expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291933627.9.0.166571519454.issue10665@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19990/unicodedata-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Thu Dec  9 23:30:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Dec 2010 22:30:27 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291933827.5.0.797418866649.issue5845@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Nosying Martin: any Windows installer concerns?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Dec  9 23:59:00 2010
From: report at bugs.python.org (Justin Peel)
Date: Thu, 09 Dec 2010 22:59:00 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>


New submission from Justin Peel <peelpy at gmail.com>:

I put the Counter's update and __missing__ methods into C code. The rest of the existing methods remain the same. The new Counter is at least 2x-10x (or more) faster for updating depending on the input. I also added a new method, update_fromsubs, which is documented below the timings for updating a Counter.

Here are a few examples to demonstrate the speed of the new update function:

Counting list(range(100))*100 - 
    Old Counter: 18.6 msec
    New Counter: 1.43
13x speed-up

Counting range(10000) - 
    Old Counter: 21.5 msec
    New Counter: 3.84 msec
5.6x speed-up

Counter generator  i % 100 for i in range(10000) - 
    Old Counter: 36.7 msec
    New Counter: 17.5 msec
2.1x speed-up

and the __missing__ method being in C makes getting missing keys about twice as fast.

Also, I added a new method, update_fromsubs, which counts subarrays/substrings of a sequence. This method only works with immutable sequences like tuples, bytes, and unicode objects. The method is of the form

update_fromsubs(seq, frame[, step[, lo[, hi]]])

where frame is the size of the subarrays, step is how far to move forward after each subarray, and lo and hi are the respective starting and ending indices to count subarrays within the sequence.

For instance,

    c = Counter()
    c.update_fromsubs('abcd', 2)

yields

    Counter({'cd': 1, 'ab': 1, 'bc': 1})

and

    d = Counter()
    d.update_fromsubs('abcd', 2, 2)

yields

    Counter({'ab': 1, 'cd: 1})

These sorts of operations could be done with generators in a manner like

    Counter(s[i:i+2] for i in range(0, len(s)-1))

but it can be about twice as fast by using update_fromsubs. Here's an example

Counting subarrays of length 2 of "ab"*10000:
    update_fromsubs:            30.8 ms
    New Counter w/ generator:   54.3 ms
    Old Counter w/ generator:   98.8 ms

This method would probably be most useful in processing strings, but there may be other uses. If it is accepted, please feel to change the method name and parameters. I especially wasn't sure what to call this method (update_fromsubsequences seemed rather long).

----------
components: Extension Modules, Library (Lib)
files: counterpatch.diff
keywords: patch
messages: 123706
nosy: jpeel, rhettinger
priority: normal
severity: normal
status: open
title: collections.Counter object in C
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file19992/counterpatch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Fri Dec 10 00:07:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Dec 2010 23:07:54 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1291936074.18.0.578269458586.issue10667@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the patch.

FWIW, I'm attaching some timing code that I've used in the past.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Fri Dec 10 00:09:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Dec 2010 23:09:29 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1291936169.49.0.81567581331.issue10667@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Added file: http://bugs.python.org/file19993/time_counter.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Fri Dec 10 00:10:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 09 Dec 2010 23:10:07 +0000
Subject: [issue10665] Update and expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291936207.07.0.529673515989.issue10665@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please, one issue per report and checkin, and no work-in-progress on the tracker. The issue of factually correcting claims about the unicodedata module and elaborations on how it works are unrelated issues.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Dec 10 00:12:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 09 Dec 2010 23:12:53 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1291936373.78.0.461179988639.issue5845@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There is no readline support on Windows at all, so I don't think the Windows installer can be affected. I'm uncertain what the proposed change to Python is at this point, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Fri Dec 10 00:24:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Dec 2010 23:24:04 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1291937044.21.0.428315105812.issue10667@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

When adding some C accelerations, we often try to keep a pure Python alternative in the stdlib, since it can then benefit other Python implementations (and easy prototyping).

If you move some of the methods inside a mixin and use multiple inheritance with the base C impl, this should be easy.
Also, the unit tests should then test both the C impl and the pure Python impl.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Fri Dec 10 00:27:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Dec 2010 23:27:18 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1291937238.41.0.325573328655.issue6422@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure why you chose 0.11 here. It should probably be 0.2 as in the command-line code.
As for applying the patch, this can't be done before 3.2 is released.

----------
nosy: +pitrou
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Fri Dec 10 02:40:37 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 10 Dec 2010 01:40:37 +0000
Subject: [issue10242] unittest's assertItemsEqual() method makes too many
	assumptions about its input
In-Reply-To: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>
Message-ID: <1291945237.75.0.766392980101.issue10242@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I have to agree that the name assertCountEqual does not work well for me as something I can read and really comprehend what it is going to do without searching for the docs or implementation to double check.  (not that assertItemsEqual did either).  'Count' does not strongly imply to me that it is expecting sequences or really tell me what it will be testing.

Brainstorming based on other suggestions i've seen and some i've made up:

  assertCountEqual             [in 3.2beta1]
  assertCountsEqual
  assertElementCountEqual      [michael.foord]
  assertElementCountsEqual
  assertItemCountEqual
  assertItemCountsEqual
  assertItemsEqual             [old, agreed to replace this]

When it comes down to Item vs Element I do like the sound of Element even though it is longer to type.

Should it be singular 'Count' (Dracula?) or plural/possessive 'Counts'?

To me "assertCountEqual" makes me think of the other assertFooEqual methods and wonder what data structure type a "Count" is.  You could argue that calling it assertCounterEqual would make sense in reference to collections.Counter but I do not think that actually ready any more explanatory when reading.

I'm sorry that this is a bikeshed.  But if we're gonna change the paint color, during the beta is a good time.

my problem with assertElementCountEqual is that being singular I could read a statement such as "self.assertElementCountEqual(listA, setB)" and assume that it is the same as "self.assertEqual(len(listA), len(setB))"

assertElementCountsEqual by virtue of the mere 's' implies to me that it is not doing a len(listA) but is instead counting up the individual elementS and comparing those counts.   So after all this rambling, I think that's my vote.

Agree/disagree/indifferent?

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Fri Dec 10 02:46:46 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 10 Dec 2010 01:46:46 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1291945606.2.0.17724300967.issue10273@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi - since I didn't chime in earlier on this: I think you made the right choice with what was decided in msg122413 and implemented in the renaming done in r86910 and the work done in issue10242.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Fri Dec 10 02:54:24 2010
From: report at bugs.python.org (Alex)
Date: Fri, 10 Dec 2010 01:54:24 +0000
Subject: [issue10668] Array tests have nonsense in them
In-Reply-To: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>
Message-ID: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

In ArraySubclassWithKwargs, when __init__ is called it doesn't actually pass self to `array.array.__init__`, this doesn't actually cause errors because the contents of the array isn't tested anywhere.

----------
components: Library (Lib)
messages: 123714
nosy: alex
priority: normal
severity: normal
status: open
title: Array tests have nonsense in them
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10668>
_______________________________________

From report at bugs.python.org  Fri Dec 10 03:29:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Dec 2010 02:29:28 +0000
Subject: [issue10668] Array tests have nonsense in them
In-Reply-To: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>
Message-ID: <1291948168.13.0.570002484264.issue10668@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This class was added by the fix for issue 1486663 in r53509.  Adding Georg as nosy since he committed it, but it seems like it would be worth fixing it in case someone else uses the class in an additional test in the future.

----------
nosy: +georg.brandl, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10668>
_______________________________________

From report at bugs.python.org  Fri Dec 10 03:29:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Dec 2010 02:29:42 +0000
Subject: [issue10668] Array tests have nonsense in them
In-Reply-To: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>
Message-ID: <1291948182.43.0.445752462595.issue10668@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10668>
_______________________________________

From report at bugs.python.org  Fri Dec 10 06:40:47 2010
From: report at bugs.python.org (Rusi)
Date: Fri, 10 Dec 2010 05:40:47 +0000
Subject: [issue10669] Remove Deprecation Warnings
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>


New submission from Rusi <rustompmody at gmail.com>:

I am trying to port some app from 2.x to 3.x
Terry Reedy suggested using 2.7
I get deprecation warnings (with -3 flag)

I would be good to have a place to check all such and have suggested solutions

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 123716
nosy: RusiMody
priority: normal
severity: normal
status: open
title: Remove Deprecation Warnings
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Fri Dec 10 07:29:05 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 10 Dec 2010 06:29:05 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1291962545.78.0.30144923179.issue10611@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Agreed. I think the "except Exception" in TestCase.run() should be "except BaseException", since BaseException could catch Exception, SystemExit, GeneratorExit, KeyboardInterrupt. The KeyboardInterrupt should be caught first. The remaining three is exactly what is needed.

Here is a patch I worked, with unittest.

----------
keywords: +patch
nosy: +ysj.ray
Added file: http://bugs.python.org/file19994/issue_10611.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10611>
_______________________________________

From report at bugs.python.org  Fri Dec 10 08:16:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Dec 2010 07:16:00 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1291965360.32.0.13091571485.issue10611@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.

----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10611>
_______________________________________

From report at bugs.python.org  Fri Dec 10 09:16:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 10 Dec 2010 08:16:54 +0000
Subject: [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

When searching docs (e.g. for http://docs.python.org/dev/search.html?q=unicode&check_keywords=yes&area=default) I'd like to filter out C API.

----------
assignee: docs at python
components: Documentation
messages: 123719
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Provide search scope limits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10670>
_______________________________________

From report at bugs.python.org  Fri Dec 10 09:37:18 2010
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Cauwelier?=)
Date: Fri, 10 Dec 2010 08:37:18 +0000
Subject: [issue10660] format() to lower and uppercase
In-Reply-To: <1291908822.96.0.536076178004.issue10660@psf.upfronthosting.co.za>
Message-ID: <1291970238.26.0.263434495229.issue10660@psf.upfronthosting.co.za>


Herv? Cauwelier <herve at itaapy.com> added the comment:

Thanks for the example. The Python 2.7 documentation about the mini-language doesn't clearly state that it is extensible and how. we see examples of formatting but not of extending.

Your example would be welcome in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10660>
_______________________________________

From report at bugs.python.org  Fri Dec 10 09:52:06 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 10 Dec 2010 08:52:06 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1291971126.31.0.00855639538583.issue10667@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Fri Dec 10 10:35:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 10 Dec 2010 09:35:11 +0000
Subject: [issue10669] Remove Deprecation Warnings
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1291973711.61.0.0304831201747.issue10669@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Are the warnings originating in your code, or in the standard library, or elsewhere?

If in the standard library, please provide specific details.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Fri Dec 10 11:02:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Dec 2010 10:02:06 +0000
Subject: [issue10668] Array tests have nonsense in them
In-Reply-To: <1291946064.7.0.737728042114.issue10668@psf.upfronthosting.co.za>
Message-ID: <1291975326.49.0.852915925524.issue10668@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87156.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10668>
_______________________________________

From report at bugs.python.org  Fri Dec 10 11:12:41 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 10 Dec 2010 10:12:41 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1291975961.57.0.14569745626.issue10516@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> That's good if it's so... can you explain why list_clear doesn't 
> guarantee that the list is empty? Why would XDECREF populate the list? 
> I don't quite understand it.


Does this mean that durning the Py_DECREF progress the list may be populated again? It's not a problem. Here is the simplest example(with applying eli's patch):


class A(object):
    def __init__(self, li):
        self._li = li
    def __del__(self):
        self._li.append(self)

li = []
li.append(A(li))
li.clear()
print(li)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Dec 10 11:26:46 2010
From: report at bugs.python.org (Rusi)
Date: Fri, 10 Dec 2010 10:26:46 +0000
Subject: [issue10669] Remove Deprecation Warnings
In-Reply-To: <1291973711.61.0.0304831201747.issue10669@psf.upfronthosting.co.za>
Message-ID: <AANLkTikWGT4V-LKHmjN90TBFgRLbuJ+AFpB6i7GpS901@mail.gmail.com>


Rusi <rustompmody at gmail.com> added the comment:

Hi Eric
Sorry for not being clear.
This is more of a feature request than a bug report as suggested by Terry
Reedy on the python mailing list (see here

http://mail.python.org/pipermail/python-list/2010-December/1262149.html

The warnings are in my code.
The main problems are (I expect) from strings/unicode/binary-strings
I am suggesting that it would be good to have a place one could go to with
each such warnings that would give explanations and possible remedies

Rusi

On Fri, Dec 10, 2010 at 3:05 PM, Eric Smith <report at bugs.python.org> wrote:

>
> Eric Smith <eric at trueblade.com> added the comment:
>
> Are the warnings originating in your code, or in the standard library, or
> elsewhere?
>
> If in the standard library, please provide specific details.
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10669>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19995/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________
-------------- next part --------------
Hi Eric<br>Sorry for not being clear.<br>This is more of a feature request than a bug report as suggested by Terry Reedy on the python mailing list (see here<br><br><a href="http://mail.python.org/pipermail/python-list/2010-December/1262149.html">http://mail.python.org/pipermail/python-list/2010-December/1262149.html</a><br>
<br>The warnings are in my code.?? <br>The main problems are (I expect) from strings/unicode/binary-strings<br>I am suggesting that it would be good to have a place one could go to with each such warnings that would give explanations and possible remedies<br>
<br>Rusi<br><br><div class="gmail_quote">On Fri, Dec 10, 2010 at 3:05 PM, Eric Smith <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Eric Smith &lt;<a href="mailto:eric at trueblade.com">eric at trueblade.com</a>&gt; added the comment:<br>
<br>
Are the warnings originating in your code, or in the standard library, or elsewhere?<br>
<br>
If in the standard library, please provide specific details.<br>
<br>
----------<br>
nosy: +eric.smith<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/issue10669" target="_blank">http://bugs.python.org/issue10669</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Dec 10 11:30:40 2010
From: report at bugs.python.org (Mher Movsisyan)
Date: Fri, 10 Dec 2010 10:30:40 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1291977040.04.0.303555213624.issue985064@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

The attached patch fixes crashes on bad input. The patch implements validation for dict and array elements as well as some resource cleanup. The tests are included as well.

----------
keywords: +patch
nosy: +mher
Added file: http://bugs.python.org/file19996/plist_validation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Fri Dec 10 11:43:11 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 10 Dec 2010 10:43:11 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1291977791.67.0.079559398485.issue10611@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

At the moment exception handling for setUp / tearDown / testMethod and cleanUp functions are all handled separately. They all have to call addError and as a result we have inconsistent handling of skips, expected failures (etc). There are separate issues for handling expected failures in setUp and skips in tearDown.

I'd like to fix all these issues by moving the exception handling into a single method and unifying the reporting of failure / error / expected failure / skip test. This will fix all these issues and nicely simplify the implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10611>
_______________________________________

From report at bugs.python.org  Fri Dec 10 12:58:42 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Dec 2010 11:58:42 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291982322.83.0.345154950852.issue10626@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've added the logging code to implement and use a logger of last resort as discussed on the thread for http://bit.ly/last-resort-handler into the py3k branch, r87157. Gist of differences is available at https://gist.github.com/736120 - so Brian could remove the STDERR_HANDLER from his code. The futures test code can set sys.stderr to an io.StringIO instance during the test; the last resort handler checks for the sys.stderr value when emitting a record, not when the handler is created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Fri Dec 10 13:00:24 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Dec 2010 12:00:24 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1291982424.54.0.610371777526.issue10626@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

s/logger of last resort/handler of last resort/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Fri Dec 10 13:16:47 2010
From: report at bugs.python.org (Kirill Subbotin)
Date: Fri, 10 Dec 2010 12:16:47 +0000
Subject: [issue10671] urllib2 redirect to another host doesn't work
In-Reply-To: <1291983407.25.0.106124609797.issue10671@psf.upfronthosting.co.za>
Message-ID: <1291983407.25.0.106124609797.issue10671@psf.upfronthosting.co.za>


New submission from Kirill Subbotin <kirrax at gmail.com>:

When you open url which redirects to another host (either with 301 or 302), HTTPRedirectHandler keeps "Host" header from the previous request, which leads to a error. Instead a host should be taken from a new location url.

Attached patch is tested with Python 2.6.5.

----------
components: Library (Lib)
files: urllib2.diff
keywords: patch
messages: 123729
nosy: Kirax
priority: normal
severity: normal
status: open
title: urllib2 redirect to another host doesn't work
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19997/urllib2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10671>
_______________________________________

From report at bugs.python.org  Fri Dec 10 13:44:23 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 10 Dec 2010 12:44:23 +0000
Subject: [issue10671] urllib2 redirect to another host doesn't work
In-Reply-To: <1291983407.25.0.106124609797.issue10671@psf.upfronthosting.co.za>
Message-ID: <1291985063.05.0.806123742799.issue10671@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Can you point me to your code and error traceback that was observed and some details about server which gave 301/302 Redirect as what was the hostname and where did it redirect to?

I don't see the code changes that you provided in the patch in the latest versions of urllib, but I am equally surprised if the condition that you said may occur. Because Host will be overridden at some point in time in the Request is made for the new redirected url.

You may want to try with python 2.7 or 2.7.1 too and report if you still face the problem.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10671>
_______________________________________

From report at bugs.python.org  Fri Dec 10 13:48:27 2010
From: report at bugs.python.org (Mayweed)
Date: Fri, 10 Dec 2010 12:48:27 +0000
Subject: [issue10672] ["with"] new in version 2.6 instead of 2.5
In-Reply-To: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>
Message-ID: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>


New submission from Mayweed <norman.denayer at atosorigin.com>:

In the documentation, the statement "with" is marked as:
"New in version 2.5."
(http://docs.python.org/reference/compound_stmts.html#the-with-statement)

This new statement is new in version 2.6 !

----------
assignee: docs at python
components: Documentation
messages: 123731
nosy: docs at python, karmaguedon
priority: normal
severity: normal
status: open
title: ["with"] new in version 2.6 instead of 2.5
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10672>
_______________________________________

From report at bugs.python.org  Fri Dec 10 14:24:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Dec 2010 13:24:44 +0000
Subject: [issue10672] ["with"] new in version 2.6 instead of 2.5
In-Reply-To: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>
Message-ID: <1291987483.99.0.136681826985.issue10672@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is in fact new in 2.5, but only available when using "from __future__ import with_statement", which the note near the end of the section details.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10672>
_______________________________________

From report at bugs.python.org  Fri Dec 10 15:36:18 2010
From: report at bugs.python.org (Brian Cain)
Date: Fri, 10 Dec 2010 14:36:18 +0000
Subject: [issue10673] multiprocess.Process join method - timeout
	indistinguishable from success
In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>
Message-ID: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>


New submission from Brian Cain <brian.cain at gmail.com>:

When calling Process' join([timeout]) method, the timeout expiration case is indistinguishable from the successful join.  I suppose the 'exitcode' attribute can deliver the necessary information, but perhaps join could stand on its own.

If join() shouldn't be changed, could we make explicit reference to the exitcode attribute in the documentation?

----------
components: Library (Lib)
files: Process_join.patch
keywords: patch
messages: 123733
nosy: Brian.Cain
priority: normal
severity: normal
status: open
title: multiprocess.Process join method - timeout indistinguishable from success
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19998/Process_join.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10673>
_______________________________________

From report at bugs.python.org  Fri Dec 10 15:58:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 10 Dec 2010 14:58:19 +0000
Subject: [issue3992] remove custom log module from distutils2
In-Reply-To: <1222645256.9.0.167855735394.issue3992@psf.upfronthosting.co.za>
Message-ID: <1291993099.17.0.291704090361.issue3992@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils2.log has been removed in f6ef30a22a24.

I?m leaving this open to remind us we want to remove the warn and announce methods.  Logging all the way!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3992>
_______________________________________

From report at bugs.python.org  Fri Dec 10 16:26:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Dec 2010 15:26:19 +0000
Subject: [issue10673] multiprocess.Process join method - timeout
	indistinguishable from success
In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>
Message-ID: <1291994779.31.0.188782140061.issue10673@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My guess is "it shouldn't", and "yes", but I've added the multiprocessing maintainers as nosy and they can answer definitively.

----------
nosy: +asksol, jnoller, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10673>
_______________________________________

From report at bugs.python.org  Fri Dec 10 16:36:34 2010
From: report at bugs.python.org (Ask Solem)
Date: Fri, 10 Dec 2010 15:36:34 +0000
Subject: [issue10673] multiprocess.Process join method - timeout
	indistinguishable from success
In-Reply-To: <1291991778.63.0.145134143934.issue10673@psf.upfronthosting.co.za>
Message-ID: <1291995394.86.0.874206890406.issue10673@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

While it makes sense for `join` to raise an error on timeout, that could possibly break existing code, so I don't think that is an option.  Adding a note in the documentation would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10673>
_______________________________________

From report at bugs.python.org  Fri Dec 10 17:46:20 2010
From: report at bugs.python.org (Giovanni Bajo)
Date: Fri, 10 Dec 2010 16:46:20 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1291999580.04.0.401878594715.issue7213@psf.upfronthosting.co.za>


Giovanni Bajo <giovannibajo at gmail.com> added the comment:

Hi Gregory, I saw your commit here:
http://code.activestate.com/lists/python-checkins/91914/

This basically means that in 3.2 it is mandatory to specify close_fds to avoid a DeprecationWarning. *BUT* there is no good value that works both on Windows and Linux if you redirect stdout/stderr, as shown in this bug.

So basically in 3.2 to avoid a warning, each and every usage of Popen() with a redirection should be guarded by an if that checks the platform. I don't think this is acceptable.

Have I misunderstood something? Also: can you please explain how the behaviour is going to change in 3.3? I assume that you are planning to change the default to True; but would that also cover Windows' singularity in redirection cases?

----------
nosy: +Giovanni.Bajo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 17:58:03 2010
From: report at bugs.python.org (Ori Avtalion)
Date: Fri, 10 Dec 2010 16:58:03 +0000
Subject: [issue10674] Unused dictmaker symbol in 2.* grammar
In-Reply-To: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>
Message-ID: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>


New submission from Ori Avtalion <ori at avtalion.name>:

Using trunk r87157

The Grammar/Grammar file defines a "dictmaker" symbol that is no longer referenced in any other symbol. It should be removed.

----------
components: Interpreter Core
messages: 123738
nosy: salty-horse
priority: normal
severity: normal
status: open
title: Unused dictmaker symbol in 2.* grammar
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10674>
_______________________________________

From report at bugs.python.org  Fri Dec 10 18:22:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Dec 2010 17:22:23 +0000
Subject: [issue10669] Remove Deprecation Warnings
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292001743.75.0.555429008923.issue10669@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Fri Dec 10 18:26:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Dec 2010 17:26:40 +0000
Subject: [issue10644] socket loses data,
	calling send()/sendall() on invalid socket does not report error and
	returns all bytes as written
In-Reply-To: <1291712486.57.0.709018850853.issue10644@psf.upfronthosting.co.za>
Message-ID: <1292002000.5.0.206368013908.issue10644@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10644>
_______________________________________

From report at bugs.python.org  Fri Dec 10 19:31:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 10 Dec 2010 18:31:18 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <AANLkTin-ZZpwwp0N5mJzTwZok19WNVpcUwaWyEUVS9BU@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Dec 9, 2010 at 6:10 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> Please, one issue per report and checkin,

The s/5.2/6.0/ issue is hardly worth a tracker ticket.   I've
committed these changes in r87159.  (Sorry for the unrelated changes -
reverted in the next checkin.)

> and no work-in-progress on the tracker.

Why?  I thought "release early, release often" was a good thing.   I
wanted to get an early feedback because we certainly don't want to
replicate the Unicode Standard in the Python documentation, but I
think at least for the category() method that returns cryptic 2-letter
codes, we should include a table explaining them.   I am not so sure
about bidirectional() or asian_width().

> The issue of factually correcting claims about the unicodedata module and elaborations on how it works are unrelated issues.

I am changing the title of the issue to make it cover only the latter.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10665>
> _______________________________________
>

----------
title: Update and expand unicodedata module documentation -> Expand unicodedata module documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Dec 10 19:42:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 10 Dec 2010 18:42:27 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1292006547.05.0.643867757273.issue10665@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +ezio.melotti, haypo, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Dec 10 19:47:01 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Fri, 10 Dec 2010 18:47:01 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292006821.43.0.485126143882.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

I'd offer two ideas.

1. Add a constant DISREGARD_FDS to the subprocess module could help. It would allow the user to specify his intent, and let the implementation choose the best action. Popen(..., close_fds=subprocess.DISREGARD_FDS) would mean that any fds additional fds are not needed, and can be closed if it is determined that it is the best course of action.

So, if DISREGARD_FDS gets passed on Windows assume close_fds=False, while on POSIX assume close_fds=True (although this has its downsides, see at the bottom).
2. Set the CLOEXEC flag on the other side of the pipes after the fork. With the attached patch, I don't get the issue I reported:

Python 3.2b1 (py3k:87158, Dec 10 2010, 20:13:57) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import *
>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE, close_fds=False)
>>> p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE, close_fds=False)
>>> p1.stdin.write(b"aaaaaaaaaaaaaaaa\n")
17
>>> p1.stdin.close()
>>> p2.stdout.read()
b'aaaaaaaaaaaaaaaa\n'
>>> 

Additional problem with close_fds=True is that if MAXFD is huge, it can cause a huge problem with performance, so perhaps the default being True isn't all that great. On Linux you can close only the open fds, but I'm not sure if that's possible on other POSIX systems.

----------
keywords: +patch
Added file: http://bugs.python.org/file19999/subprocess-cloexec-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 20:15:15 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Fri, 10 Dec 2010 19:15:15 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292008515.18.0.22370411974.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

The cloexec approach still doesn't help with issue 2320. In fact, with threading and people calling subprocess from multiple threads, *this* issue wouldn't be fixed with my patch either unless mutexes are used. It's impossible to avoid a race here with threads and no mutex as far as I can tell. It would mean that the creation of the pipe, the fork and the setting of the CLOEXEC flag needs to be done atomically... yikes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 20:20:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Dec 2010 19:20:45 +0000
Subject: [issue10674] Unused dictmaker symbol in 2.* grammar
In-Reply-To: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>
Message-ID: <1292008845.87.0.478550283528.issue10674@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10674>
_______________________________________

From report at bugs.python.org  Fri Dec 10 20:30:35 2010
From: report at bugs.python.org (Giovanni Bajo)
Date: Fri, 10 Dec 2010 19:30:35 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292009435.61.0.811362413886.issue7213@psf.upfronthosting.co.za>


Giovanni Bajo <giovannibajo at gmail.com> added the comment:

Setting CLOEXEC on the pipes seems like a very good fix for this bug. I'm +1 on it, but I think it should be the default; instead, your proposed patch adds a new argument to the public API. Why do you think it's necessary to do so?

At the same time, we need a solution to handle close_fds, because the current status of the 3.2 with the DeprecationWarning (on 90% of subprocess uses in the world, if it ever gets backported to 2.7) and no way to fix it in a multi-platform way is really sad.

I don't think a new constant DISREGARD_FDS is necessary. I think we can just use "None" as intermediate default (just like the current 3.2 does), and later switch it to True. The only further required action is to make "True" always work on Windows and never error out (just make it do nothing if there are some redirections), which is an obviously good thing to do to increase portability of subprocess.

Otherwise, if this can't make 3.2, I think the DeprecationWarning should be reverted until we agree on a different solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 20:44:05 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Fri, 10 Dec 2010 19:44:05 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292010245.05.0.736072945409.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file19999/subprocess-cloexec-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 20:44:30 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Fri, 10 Dec 2010 19:44:30 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292010270.39.0.153248664939.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

> I'm +1 on it, but I think it should be the default; instead, 
> your proposed patch adds a new argument to the public API. Why do you 
> think it's necessary to do so?

I don't think it's necessary. I put it there because when I was testing I thought it might help. For example, you might want to keep the pipes open and then open another process with close_fds=False, thus changing the current default might cause some regressions in some software and an argument would allow an easier transition. I updated the patch removing anything unnecessary. Though it still has a huge race when used with threading.

----------
Added file: http://bugs.python.org/file20000/subprocess-cloexec-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 20:58:36 2010
From: report at bugs.python.org (Jay Moorthi)
Date: Fri, 10 Dec 2010 19:58:36 +0000
Subject: [issue10675] unittest should have an assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>


New submission from Jay Moorthi <moorthi at gmail.com>:

It would be useful to have a new assert method in the unittest.TestCase class that checks to see if a value has changed.  I wrote a quick and dirty version like so:

class MySpecialTestCase(unittest.TestCase):
    @contextmanager
    def assertChanges(self, thing, attr=None, by=None):
        def get_value(thing, attr):
            if callable(thing):
                value = thing()
            else:
                value = getattr(thing, attr)
            return value

        old_value = get_value(thing, attr)
        yield
        new_value = get_value(thing, attr)

        if by is None:
            self.assertNotEqual(new_value, old_value)
        else:
            self.assertEqual(new_value - old_value, by)

I'm sure something better can be done to take better advantage of the unittest module's diffing tools, etc.

----------
messages: 123745
nosy: Jay.Moorthi
priority: normal
severity: normal
status: open
title: unittest should have an assertChanges context manager
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10675>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:00:16 2010
From: report at bugs.python.org (Giovanni Bajo)
Date: Fri, 10 Dec 2010 20:00:16 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292011216.84.0.483904872487.issue7213@psf.upfronthosting.co.za>


Giovanni Bajo <giovannibajo at gmail.com> added the comment:

Would you mind elaborating on where is the race condition?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:03:08 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 10 Dec 2010 20:03:08 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1292011388.95.0.378222891851.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101210.zip is a new version of the regex module.

I've extended the additional checks of the previous version.

It has been tested with Python 2.5 to Python 3.2b1.

----------
Added file: http://bugs.python.org/file20001/issue2636-20101210.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:10:22 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Fri, 10 Dec 2010 20:10:22 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292011822.05.0.35783100553.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

It's almost exactly the same race condition as the one described in issue 2320. The pipes are created and stay without the CLOEXEC flag for a while (until the process has been forked and fcntl has been called). During that time another thread can launch a subprocess, the subprocess will inherit the pipe, and there might be a hang similar to the one described here (or in issue 2320).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:12:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Dec 2010 20:12:57 +0000
Subject: [issue10675] unittest should have an assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1292011977.12.0.555625782612.issue10675@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think this is the kind of thing where you are *much* better off writing a specialized assert method that exactly fits your use case.  There are too many variations on this theme, IMO, for it to make sense as an stdlib method.

----------
nosy: +michael.foord, r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10675>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:20:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Dec 2010 20:20:41 +0000
Subject: [issue10675] unittest should have an assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1292012441.8.0.114932105049.issue10675@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10675>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:25:46 2010
From: report at bugs.python.org (Philip Bober)
Date: Fri, 10 Dec 2010 20:25:46 +0000
Subject: [issue10676] Confusing note in Numeric Types
In-Reply-To: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>
Message-ID: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>


New submission from Philip Bober <pdbober at gmail.com>:

In the Python Standard Library reference, section 5.4: Numeric Types, the table of operators/functions has the following unclear note:

(4)Complex floor division operator, modulo operator, and divmod().
   Deprecated since version 2.3: Instead convert to float using abs() if appropriate.

The intention of this note is to indicate that //,%, and divmod shouldn't be used with complex numbers, but the phrasing is bad and the note being on generic operators makes it sound like the operators themselves are deprecated, not just for complex numbers. 

There was an earlier bugfix (621708, on the previous tracker. Archive: http://mail.python.org/pipermail/python-bugs-list/2002-October/013913.html) which fixed this bad wording elsewhere in the docs (Section 5.6 Binary arithmetic operations in the Python Reference Manual) but it seems the same wording was in both documents and it was only patched in one of them. 

It was replaced with:
"Deprecated since version 2.3: The floor division operator, the modulo operator, and the divmod() function are no longer defined for complex numbers. Instead, convert to a floating point number using the abs() function if appropriate."

----------
assignee: docs at python
components: Documentation
messages: 123750
nosy: Philip.Bober, docs at python
priority: normal
severity: normal
status: open
title: Confusing note in Numeric Types
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10676>
_______________________________________

From report at bugs.python.org  Fri Dec 10 21:59:26 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 10 Dec 2010 20:59:26 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292014766.86.0.102326267848.issue10667@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Fri Dec 10 22:01:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Dec 2010 21:01:42 +0000
Subject: [issue10675] unittest should have an assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1292014902.29.0.742402633865.issue10675@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with David Murray.  Usually you care about the specific value changed to, not whether it changed at all.  The changed-by variant is even more specialized and you're better of using assertEqual since you know what the new value is supposed to be:

  assertEqual(thing.attr, x)
     ...
  assertEqual(thing.attr, x+by)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10675>
_______________________________________

From report at bugs.python.org  Fri Dec 10 22:02:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Dec 2010 21:02:58 +0000
Subject: [issue10675] unittest should have an assertChanges context manager
In-Reply-To: <1292011116.36.0.95630190465.issue10675@psf.upfronthosting.co.za>
Message-ID: <1292014978.77.0.0647365133151.issue10675@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for submitting the idea though.
Perhaps, post it on the ASPN Cookbook
or on the newsgroup to see if others
are interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10675>
_______________________________________

From report at bugs.python.org  Fri Dec 10 22:23:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 10 Dec 2010 21:23:10 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1292016190.46.0.950604496476.issue10665@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In issue10665.diff, I completed the character examples in the general categories table.

----------
Added file: http://bugs.python.org/file20002/issue10665.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Fri Dec 10 23:02:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Dec 2010 22:02:08 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292018528.27.0.0845844570243.issue7213@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Adding the 3.2 release manager: a potential release blocker?)

----------
nosy: +georg.brandl, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Fri Dec 10 23:31:08 2010
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Dec 2010 22:31:08 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292020268.13.0.0937672840874.issue2690@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Not sure this worth a patch, to me it looks like a removal of a single word. But here it goes anyway.

----------
nosy: +SilentGhost
Added file: http://bugs.python.org/file20003/stdtypes.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sat Dec 11 00:04:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 10 Dec 2010 23:04:41 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <AANLkTin-ZZpwwp0N5mJzTwZok19WNVpcUwaWyEUVS9BU@mail.gmail.com>
Message-ID: <4D02B206.4060905@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Why?  I thought "release early, release often" was a good thing.

Create a branch for that, or post an issue on Rietveld. W-I-P IMO
confuses people reviewing the patches, running into the same ones
over-and-over again, only to find out every time "it's not ready yet".
So the natural reaction is to close it as rejected, for it being
incomplete.

Regards,
Martin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Sat Dec 11 00:09:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 10 Dec 2010 23:09:26 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1292022566.21.0.51776102591.issue10542@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

In bltinmodule.c, it looks like some of the indentation doesn't line up?

Bikeshedding aside, it looks good to me.

I agree with Eric Smith that the first part macro name usually refers to the type of the first argument (or the type the first argument points to).  Examples:

 - Py_UNICODE_ISSPACE : Py_UNICODE -> int
 - Py_UNICODE_TOLOWER : Py_UNICODE -> Py_UNICODE
 - Py_UNICODE_strlen: Py_UNICODE * -> size_t

This is true elsewhere in the code as well:

 - PyList_GET_SIZE : PyListObject * -> Py_ssize_t

Yes, I know there are some unfortunate exceptions. ;-)

I agree that it would be nice if something in the name hinted that the return type was Py_UCS4 though.

Marc-Andre Lemburg wrote:
>  The first argument of the macro can be any array, not just
> Py_UNICODE*, but also Py_UCS4* or even int*.

It's true that macros in C do not have any type safety.  While technically passing a Py_UCS4 * will work, on a UCS2 build it would needlessly check the Py_UCS4 data for surrogates.  I think we should discourage that.

You can also technically pass a PyListObject * to PyTuple_GET_SIZE, but that's also not a good idea. ;-)

Alexander Belopolsky wrote:
> The issue is that once in in the process of reading the codepoint, it
> is determined whether the code point is BMP or non-BMP.  Testing the
> result again in order to write it is somewhat wasteful.  I don't
> think this would matter in practice, but would like to hear
> alternative opinions before moving further.

If the common pattern is:

         ch = Py_UNICODE_NEXT(rp, end);
         uc = Py_UNICODE_SOME_TRANSFORMATION(ch);
         Py_UNICODE_PUT_NEXT(wp, uc);

The second check for surrogates in Py_UNICODE_PUT_NEXT is necessary, unless you can prove that Py_UNICODE_SOME_TRANSFORMATION will never transform characters < 0x10000 into characters > 0x10000 or vice versa.  

Can we prove will always be the case, for current and future versions of Unicode, for all or almost-all of the transformations we care about?

Answering that question and figuring out what to do about it are probably more trouble than it's worth.  If a particularly point proves to be a bottleneck, we can always specialize the code there later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Dec 11 00:25:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 10 Dec 2010 23:25:07 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1292023507.61.0.393962871298.issue985064@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

One review comment: the patch adds a new exception class that is used for the errors that are now additionally detected.  Elsewhere plistlib uses non-specific exception classes like ValueError.  If starting from scratch, it might be better to consistently use a specific exception class but that would create incompatibilities if changed now.  I don't see a compelling need to add one now just for these errors.  (But, if kept, it should be added to the docs.)  Otherwise, looks good to me.

Thanks for taking this on!

----------
nosy: +ned.deily, ronaldoussoren
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Sat Dec 11 01:26:45 2010
From: report at bugs.python.org (Justin Peel)
Date: Sat, 11 Dec 2010 00:26:45 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292027205.69.0.484206035124.issue10667@psf.upfronthosting.co.za>


Justin Peel <peelpy at gmail.com> added the comment:

I've done as Antoine asked and made a pure Python PyCounter class and a C-enhanced Counter class that both use the mixin CounterBase class. I also added to the tests so that both PyCounter and Counter are tested. I left the update_fromsubs() method in Counter for now, but haven't made a Python equivalent function for PyCounter in case the method is rejected.

Also, I realized that my build was still in debug mode so those benchmark weren't quite accurate (Oops). The Counter class is only 4-6x faster for most cases. That's still good, but not quite as good as I'd previously reported.

Lastly, I thought of one more method that could be quite useful. Say that you have a list like [('apples',4),('oranges',5),('apples',8)] where the second element in each tuple indicates how many of them there are. The resultant Counter should have {'apples': 12, 'oranges':5}. We don't really have a good way to count this, but we could add a small method like the following:

    def fromitems(self, items):
        for key, value in items:
            self[key] += value

and I could easily make a C function for it. I think that this simple method could be very useful to some people. What do you all think of this addition?

----------
Added file: http://bugs.python.org/file20004/counterpatch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Sat Dec 11 01:43:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Dec 2010 00:43:26 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292028206.9.0.518089097981.issue2690@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r87162

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sat Dec 11 02:01:47 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Dec 2010 01:01:47 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292029307.89.0.846638919494.issue10667@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would like this API to "sit and cook" for a good while.  There are many possible ways to add more methods and most be end-up being YAGNI. 
Also, my experience with dict.fromkeys() is that a fair number of people get confused by alternative constructors.  So, at this point I have zero interest in adding from_items().

Am taking the C optimizations under advisement.  In the meantime, there is no need to keep submitting patch variations.  The question is less how-to-do-it and more a question of whether-to-do-it.  We try not to add an alternate C paths unless a feature is an important building block.  There is an on-going maintenance cost and a risk of slightly different behaviors (at a minimum, the tracebacks look different and the code can't be traced through pdb).  That being said, there is a nice speed-up to be had, so I'll give that some weight.

----------
priority: normal -> low
resolution:  -> later

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Sat Dec 11 02:19:22 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 01:19:22 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292030362.73.0.357891821915.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The other major change for ranges is that "in" and "not in" are no longer inefficient for actual instances of int (it does an arithmetic calculation instead of a linear search).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sat Dec 11 02:33:00 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 01:33:00 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292031180.77.0.055060531128.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

I created another patch that attempts to create the pipes atomically.

On GNU/Linux, if pipe2 is available, it uses it to create the pipes, and there is no race. On other POSIX platforms, pipe and fcntl are called without releasing the GIL - relying on the fact that _posixsubprocess.fork_exec doesn't release the GIL either, so the two can't run at the same time (bonus: os.fork doesn't release the GIL either). I can't reproduce neither issue 7213 nor issue 2320 with either implementation, so the patch seems to fix them.

Issues:
1. If the _posixsubprocess module isn't compiled, the race still exists (well, without it subprocess isn't safe to use with threads anyway).
2. On GNU/Linux systems where glibc was compiled with kernel headers >=2.6.27, but the running kernel is <2.6.27, the subprocess module won't work. (There should be a fix for that?)
3. I have no way to tell that the non-Linux implementation works for sure. I've been running it in an endless loop, and so far there have been no hangs (*), but that doesn't mean that it doesn't have a rare race that's beyond my comprehension. With pipe2() you can be certain, but I have my doubts about the other implementation.

All unit tests seem to pass.

(*) Actually, I *thought* it hang on my first attempt, but I interrupted the process too soon to tell for sure. No hangs after that. :(

----------
Added file: http://bugs.python.org/file20005/subprocess-cloexec-atomic-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:13:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 02:13:29 +0000
Subject: [issue678250] test_mmap failing on AIX
Message-ID: <1292033609.85.0.77006165837.issue678250@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed the patch_flush_mmap patch to 3.1 in r87163 and 2.7 in r87164.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:20:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Dec 2010 02:20:42 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292034042.67.0.238101455591.issue2690@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Is the in/not-in fast path in 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:20:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 02:20:58 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292034058.87.0.182382048924.issue7213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you add a test to your patch?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:35:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 02:35:51 +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: <1292034951.63.0.743876417515.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

issue6697-lsprof.diff:
 - Oh, I did recently a similar change on PyModule: I created PyModule_GetFilenameObject()
 - "PyObject * mod" => "PyObject *mod"
 - modname is not initialized if fn->m_module (mod) is NULL => initialize modname to NULL
 - there is a reference leak (modname)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:41:14 2010
From: report at bugs.python.org (Justin Peel)
Date: Sat, 11 Dec 2010 02:41:14 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292035274.67.0.0719878252972.issue10667@psf.upfronthosting.co.za>


Justin Peel <peelpy at gmail.com> added the comment:

Okay, I was done submitting. I thought that Antoine was asking for a version that kept a pure Python version so I did that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:50:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 02:50:38 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292035838.91.0.619912762631.issue10642@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Yes, I patched the C code to not clear exceptions anymore at startup: r78826 (issue #3137). But this issue is different: here the bug is in the 3rd party module (loaded by site.py), not in Python, and Donald proposes to *ignore* errors (where I did the opposite).

> This places python at the mercy of bugs in third-party software.

Why do you consider this as a bug? Yes, Python allows to be extended by 3rd party softwares. And if you install bogus extensions, you break your Python setup.

Ignore errors is never a good idea. How would you notice that the extension is disabled because it is bogus? I prefer explicit errors to force the user to fix its setup.

Extract of the Gentoo issue:

<< The direct cause of your problem is that you manually created
/usr/lib64/python2.7/site-packages/zope/__init__.py file. Please remove it: rm -f /usr/lib64/python2.7/site-packages/zope/__init__.py* >>

I close this issue because I think that ignore errors is not a good idea.

If you disagree, you can still comment this issue, or reopen it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 03:52:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 02:52:52 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1292035972.54.0.700475453794.issue2857@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I wonder if tkinter should use this encoding.

Tkinter is used to build graphical interfaces. I don't think that users write nul bytes with their keyboard. But there is maybe a use case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Sat Dec 11 04:38:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 03:38:51 +0000
Subject: [issue10492] test_doctest fails with iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1292038731.53.0.626465346525.issue10492@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You can reproduce the bug with:

$ LANG=fr_FR.iso885915 at euro ./python -c 'import pdb; pdb.Pdb(nosigint=True).run("exec(%r)" % "x=12")'
> /home/haypo/prog/SVN/py3k/Lib/encodings/iso8859_15.py(15)decode()
-> return codecs.charmap_decode(input,errors,decoding_table)
(Pdb) quit

(it should print "x=12" in the backtrace, not ...iso8859_15.py...)

Simplified C backtrace: builtin_exec() -> PyRun_StringFlags() -> PyAST_CompileEx() -> makecode() -> PyUnicode_DecodeFSDefault().

ISO-8859-15 codec is implemented in Python whereas ASCII, ISO-8859-1 and UTF-8 are implemented in C. Pdb stops at the first Python instruction. The user expects that the first instruction is "x=12", but no, the real first Python instruction is calling ISO-8859-15 to decode the byte string "<string>" (script filename).

I see two solutions:
 - set the trace function later. Eg. replace exec(cmd, ...) by code=compile(cmd, ...) + exec(code) and set the trace function after the call to compile. I don't know if both codes are equivalent.
 - reimplement ISO-8859-15 in Python: it doesn't solve the issue, there are other encodings implemented in Python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Sat Dec 11 04:46:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 03:46:54 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292039214.4.0.299971646352.issue10515@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What do you mean by "there is a test for this case in csv.py"?  If I run sniffer against "abcde\ndefgh\n" I get a delimiter of 'e'.  If I run it against 'a\nb\n', I get the could not determine delimiter error.

Attached is a reformulated test case that lets us see the errors individually and easily add more.  With this set of 10 tests, two pass without your patches (as you knew; those are your tests), and we have 4 failures and 4 errors.  With p1 applied we have 4 failures and 3 errors.  With p2 applied we have 5 failures.

As I said, I'm not at all sure what the results *should* be for various of these cases.  Certainly the long standing existing behavior seems to be to return one of the characters in an unquoted multicharacter sequence. 

That said, it seems like your patch p1 is good, but as you discovered not sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sat Dec 11 04:47:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 03:47:58 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292039278.38.0.101255027267.issue10515@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Forgot to attach the patch.

----------
Added file: http://bugs.python.org/file20006/csv_delimiter_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sat Dec 11 05:00:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 04:00:07 +0000
Subject: [issue10492] test_doctest fails with iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1292040007.02.0.942410832239.issue10492@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See a more complex solution: #3080 (don't decode the filename in the parser, keep unicode strings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Sat Dec 11 05:03:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 04:03:53 +0000
Subject: [issue1574217] isinstance swallows exceptions
Message-ID: <1292040233.1.0.789780729463.issue1574217@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Upon reflection I think the risk of breaking apparently working programs is higher than the benefit to be obtained from backporting this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574217>
_______________________________________

From report at bugs.python.org  Sat Dec 11 05:06:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 04:06:43 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292040403.27.0.902596798021.issue10642@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/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 05:18:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Dec 2010 04:18:10 +0000
Subject: [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292041090.49.0.0713191155362.issue10669@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The issue is not the specific warnings Rusi got but how, in general, one can get more information when the warnings are too cryptic to deal with.

One response might be that DeprecationWarnings should be much wordier than they are -- a paragraph of a few sentences rather than just a minimal sentence. Another might be that each release have a HOW-TO doc or What's New section with a paragraph for each one added to that release.

Currently, information is scattered among pydev posts, tracker issues, commit messages, News entries, and maybe What's new.

----------
nosy: +rhettinger, terry.reedy
title: Remove Deprecation Warnings -> Document Deprecation Warnings and how to fix
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Sat Dec 11 05:26:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Dec 2010 04:26:36 +0000
Subject: [issue10674] Unused dictmaker symbol in 2.* grammar
In-Reply-To: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>
Message-ID: <1292041596.61.0.272302265094.issue10674@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r87167

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10674>
_______________________________________

From report at bugs.python.org  Sat Dec 11 05:34:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Dec 2010 04:34:28 +0000
Subject: [issue10674] Unused dictmaker symbol in 2.* grammar
In-Reply-To: <1292000283.53.0.266717030869.issue10674@psf.upfronthosting.co.za>
Message-ID: <1292042068.76.0.301985254302.issue10674@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Your links are to py3k branch, where dictmaker does not appear.
http://svn.python.org/view/python/branches/release27-maint/Grammar/Grammar?view=markup
should that Benjamin just removed it from 2.7.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10674>
_______________________________________

From report at bugs.python.org  Sat Dec 11 06:34:49 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 05:34:49 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292045689.27.0.603047115528.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, I believe it was added as part of the .index() and .count() implementation.

Checking the source, there's definitely no sq_contains implementation in 3.1 or 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sat Dec 11 07:55:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 11 Dec 2010 06:55:04 +0000
Subject: [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292050504.73.0.205212664116.issue10669@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The deprecation notes in the doc should be quite easy to find and can be more verbose, but there are a few cases where the deprecation is not about a specific function but something more "abstract" (e.g. some syntax change, or the "Overriding __eq__ blocks inheritance of __hash__ in 3.x" reported by the OP).
Listing new deprecations in the what's new it's a good idea, but otherwise a clear message (that also suggests how to fix the problem) and a deprecation note in the doc (using the '.. deprecated::' directive) should be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Sat Dec 11 09:10:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Dec 2010 08:10:46 +0000
Subject: [issue10676] Confusing note in Numeric Types
In-Reply-To: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>
Message-ID: <1292055046.66.0.0302368328058.issue10676@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r87169.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10676>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:39:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:39:10 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

"make altinstall" is currently installing python3.2m rather than python3.2.

Since PEP 3149 makes no mention of changing the executable name, this should be fixed to correctly install the executable as python3.2.

I suspect this will also affect a "make install", but will be obscured in that case since the python3 symlink will still do the right thing. (I haven't tried it, since I don't want to clobber the Canonical provided 3.1 installation)

----------
assignee: barry
messages: 123782
nosy: barry, georg.brandl, ncoghlan
priority: release blocker
severity: normal
status: open
title: "make altinstall" includes ABI codes in versioned executable name
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:39:28 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:39:28 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292067568.81.0.309543693855.issue10677@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
components: +Build
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:44:30 2010
From: report at bugs.python.org (Phyo Arkar Lwin)
Date: Sat, 11 Dec 2010 11:44:30 +0000
Subject: [issue10678] email.utils.mktime_tz Giving wrong result ,
	by ignoring Timezone  that comes from value of  parsedate .
In-Reply-To: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>
Message-ID: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>


New submission from Phyo Arkar Lwin <phyo.arkarlwin at gmail.com>:

DESCRIPTION:

I am trying to parse Time Zone information out of email messages and i found out that mktime_tz is totally ignoring TimeZone information from parsedate_tz.


VERSION: 2.6.5
CODE and RESULTS:


from time import mktime
from email.utils import parsedate,parsedate_tz,formatdate,mktime_tz

parsedate_tz('Sat, 10 Apr 2004 03:50:19 +400')
>>> (2004, 4, 10, 3, 50, 19, 0, 1, -1, 14400)


mktime_tz(parsedate_tz('Sat, 10 Apr 2004 03:50:19 +400'))
>>>1081554619.0
mktime(parsedate('Sat, 10 Apr 2004 03:50:19'))
>>>1081545619.0

Same????

formatdate(mktime_tz(parsedate_tz('Sat, 10 Apr 2004 03:50:19 +400')))
>>>'Fri, 09 Apr 2004 23:50:19 -0000' # WRONG TOTALLY

Expected Result:
>>>'Sat, 10 Apr 2004 03:50:19 +400'

----------
components: None
messages: 123783
nosy: Phyo.Arkar.Lwin
priority: normal
severity: normal
status: open
title: email.utils.mktime_tz Giving wrong result , by ignoring Timezone  that comes from value of  parsedate .
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10678>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:47:04 2010
From: report at bugs.python.org (Phyo Arkar Lwin)
Date: Sat, 11 Dec 2010 11:47:04 +0000
Subject: [issue10678] email.utils.mktime_tz Giving wrong result ,
	by ignoring Timezone  that comes from value of  parsedate_tz .
In-Reply-To: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>
Message-ID: <1292068024.36.0.930981106574.issue10678@psf.upfronthosting.co.za>


Changes by Phyo Arkar Lwin <phyo.arkarlwin at gmail.com>:


----------
title: email.utils.mktime_tz Giving wrong result , by ignoring Timezone  that comes from value of  parsedate . -> email.utils.mktime_tz Giving wrong result , by ignoring Timezone  that comes from value of  parsedate_tz .

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10678>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:47:38 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:47:38 +0000
Subject: [issue10679] "make altinstall" will clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

"make altinstall" installs "2to3", "pydoc3" and "idle3" without version specific names.

This was at least a deliberate decision in the case of 2to3, but there doesn't appear to be any reason not to use a properly qualified version suffix on the pydoc and idle executables.

----------
messages: 123784
nosy: benjamin.peterson, georg.brandl, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: "make altinstall" will clobber OS provided scripts
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:50:59 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:50:59 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292068259.39.0.575486490446.issue10679@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Softened the wording, since OS packages will often omit installing any executable files other than the main python binary.

----------
title: "make altinstall" will clobber OS provided scripts -> "make altinstall" may clobber OS provided scripts

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:51:39 2010
From: report at bugs.python.org (Phyo Arkar Lwin)
Date: Sat, 11 Dec 2010 11:51:39 +0000
Subject: [issue10678] email.utils.mktime_tz Giving wrong result ,
	by ignoring Timezone  that comes from value of  parsedate_tz .
In-Reply-To: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>
Message-ID: <1292068299.31.0.957079740615.issue10678@psf.upfronthosting.co.za>


Changes by Phyo Arkar Lwin <phyo.arkarlwin at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10678>
_______________________________________

From report at bugs.python.org  Sat Dec 11 12:52:08 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Dec 2010 11:52:08 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292068328.27.0.145216458707.issue10677@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The other thing that makes this clearly an error is, of course, the fact that all the shebang lines expect the executable to be called "python3.2"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 13:32:35 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 11 Dec 2010 12:32:35 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1292039214.4.0.299971646352.issue10515@psf.upfronthosting.co.za>
Message-ID: <19715.28462.430900.259411@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>From the comment in the test_csv.py:

+        # XXX: I don't know what the correct behavior should be for these.
+        # Currently the first one raises an error that the delimiter can't
+        # be determined while the second one returns '\r'.  The second
+        # is obviously.
+        ('"a,b,c,d"\ne',  ''),
+        ('"a,b,c,d"\r\ne', ''),

Obviously what?  My guess would be "wrong".  In the absence of any other
information \r\n has to be treated as a line separator.  It shouldn't be
considered as two separate characters, even in such a devoid-of-clues test
case.

Is the empty string a valid delimiter?  I've never tried it and it's been a
long time since I looked at any of the code.  I do use single-column CSV
files from time-to-time though.  I don't think a ',' would be a completely
unreasonable fallback scenario either.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sat Dec 11 13:34:58 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 12:34:58 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292070898.93.0.483472954444.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

I attached unit tests that test that cloexec is properly set. I can't test my tests too well with the unpatched version because runtests.sh is too complicated to use, and doesn't print any useful output by default.

----------
Added file: http://bugs.python.org/file20007/subprocess-cloexec-atomic-py3k-tests1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 13:45:59 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 12:45:59 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292071559.4.0.782032215342.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file20007/subprocess-cloexec-atomic-py3k-tests1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 13:46:13 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 12:46:13 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292071573.41.0.415965199363.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20008/subprocess-cloexec-atomic-py3k-tests1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 13:52:08 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 12:52:08 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292071928.4.0.51288190766.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file20008/subprocess-cloexec-atomic-py3k-tests1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 13:52:18 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 12:52:18 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292071938.68.0.737721365477.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20009/subprocess-cloexec-atomic-py3k-tests1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 14:38:48 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 11 Dec 2010 13:38:48 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1292074728.37.0.516895415847.issue969718@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue969718>
_______________________________________

From report at bugs.python.org  Sat Dec 11 14:46:04 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Dec 2010 13:46:04 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292075164.35.0.578651650439.issue10642@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suggest to:
- Print path to the .pth file, which causes exception. Current traceback doesn't help in finding the cause of problem:

# echo "import nonexistent" > /usr/lib64/python3.2/site-packages/some_file.pth
# python3.2 -c pass
Traceback (most recent call last):
  File "/usr/lib64/python3.2/site.py", line 520, in <module>
    main()
  File "/usr/lib64/python3.2/site.py", line 509, in main
    known_paths = addsitepackages(known_paths)
  File "/usr/lib64/python3.2/site.py", line 301, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib64/python3.2/site.py", line 177, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib64/python3.2/site.py", line 148, in addpackage
    exec(line)
  File "<string>", line 1, in <module>
ImportError: No module named nonexistent

- Maybe change error into warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:04:55 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 14:04:55 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1292076295.65.0.903798589953.issue6559@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

The patch doesn't seem to work.

I added this before closerange in _close_all_but_a_sorted_few_fds:

print("Closing", start_fd, "up to", fd, "exclusive")

And used the attached script to run as a subprocess to check for open fds (taken from my tests patch for issue 7213).

Here's the result:
Python 3.2b1 (py3k:87158M, Dec 11 2010, 02:55:28) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import os
>>> import subprocess
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=False).wait()
0,1,2
0
>>> os.pipe()
(3, 4)
>>> os.pipe()
(5, 6)
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=False).wait()
0,1,2,3,4,5,6
0
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=True).wait()
0,1,2
0
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=True, pass_fds=(6,)).wait()
0,1,2,6
0
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=True, pass_fds=(3,)).wait()
0,1,2
0
>>> subprocess._posixsubprocess = None
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=True, pass_fds=(6,)).wait()
Closing 3 up to 6 exclusive
Closing 7 up to 8 exclusive
0,1,2,6
0
>>> subprocess.Popen([sys.executable, 'fd_status.py'], close_fds=True, pass_fds=(3,)).wait()
Closing 3 up to 8 exclusive
0,1,2
0

I also attach a possible test for pass_fds, and an example fix for Python-only implementation. The test requires either my tests patch for issue 7213, or the attached fd_status.py to be put in subprocessdata subdir of Lib/test. The fixed Python implementation passes my test and works fine in the console, I haven't tried the C one. (I don't have a patch for the fix, since it would conflict with the patches for issue 7213.)

----------
nosy: +milko.krachounov
Added file: http://bugs.python.org/file20010/fd_status.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:05:13 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 14:05:13 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1292076313.12.0.542875867092.issue6559@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20011/test_pass_fds.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:05:33 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 14:05:33 +0000
Subject: [issue6559] [PATCH]add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1292076333.79.0.203723607426.issue6559@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20012/subprocess-pass_fd_fix_example.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:10:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 14:10:42 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292076642.82.0.731389852944.issue10515@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, obviously wrong.  I forgot to finish editing the comment.

I think a fallback of ',' makes more sense than ''.  What would a delimiter of nothing mean?  I don't think the unquoted case can be changed for backward compatibility reasons, so those tests I added should presumably be changed to confirm the existing behavior (with an appropriate comment).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:12:06 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 14:12:06 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292076726.17.0.865765613006.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

I add a patch that tests close_fds (there's no test for close_fds), that requires the tests1 patch. By the way, should there be a test for the atomicity of the operations?

----------
Added file: http://bugs.python.org/file20013/subprocess-cloexec-atomic-py3k-tests2-close_fds.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:12:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 14:12:22 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292076742.4.0.52733673408.issue10642@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like the suggestion of turning it into a warning, myself, but you are right that at the least the error message should be improved.

----------
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:21:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Dec 2010 14:21:16 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292077276.15.0.492178779255.issue10677@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Nice, definitely a blocker.

(BTW, if you configured without any specific --prefix, you shouldn't clobber anything installed by the distribution...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 15:21:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Dec 2010 14:21:44 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292077304.67.0.347593786065.issue10679@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this already irked me with previous versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Sat Dec 11 16:31:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 15:31:25 +0000
Subject: [issue10678] email.utils.mktime_tz Giving wrong result ,
	by ignoring Timezone  that comes from value of  parsedate_tz .
In-Reply-To: <1292067870.01.0.821446492471.issue10678@psf.upfronthosting.co.za>
Message-ID: <1292081485.84.0.900083432098.issue10678@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

mktime_tz is documented as turning the input into a *UTC* timestamp.  That's what your example shows it doing.

There is an open issue elsewhere in this tracker for providing a way to round-trip RFC2822 timestamps.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10678>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:00:49 2010
From: report at bugs.python.org (Mads Michelsen)
Date: Sat, 11 Dec 2010 16:00:49 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>


New submission from Mads Michelsen <madchine at gmail.com>:

This is a follow-up to Issue 58 from the Google Project Hosting bug tracker (http://code.google.com/p/argparse/issues/detail?id=58). I couldn't find any equivalent/re-posting of it here, so I took the liberty of creating a new one - despite the bug being marked 'WontFix' on Google. The reason for this is that I cannot make the suggested workaround... well, work. 

The root problem: the argparse parser add_mutually_exclusive_group method does not accept title or description arguments. 

The workaround: steven.bethard suggests on google to create a 'straight' dummy group (i.e. one made using the title-accepting add_argument_group method) and then attach the mutually exclusive group to the dummy group - which is attached to the parser itself. 

The problem: while the group does appear as a group with title on the help output, the group does not appear to actually _be_ mutually exclusive (I get no objections to running several arguments from the same group together) nor does it display as mutually exclsuive on the help output. 

Please see attached file for code + resulting output.

(I hope I'm doing this right - this is my first bug report, so bear with and instruct me if I'm getting it wrong)

----------
components: Library (Lib)
files: argsconfig.txt
messages: 123797
nosy: Mads.Michelsen
priority: normal
severity: normal
status: open
title: argparse: titles and add_mutually_exclusive_group don't mix (even with workaround)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20014/argsconfig.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:01:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Dec 2010 16:01:44 +0000
Subject: [issue10642] site.py crashes on python startup due to defective .pth
	file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292083304.04.0.932301448403.issue10642@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Aren?t there studies that show that people don?t read warnings?  I?m +0 on a warning and +1 on an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:02:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Dec 2010 16:02:32 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292083352.13.0.96180669336.issue10677@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:03:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Dec 2010 16:03:32 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292083412.11.0.0263590502237.issue10679@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:09:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Dec 2010 16:09:47 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292083787.35.0.502656542782.issue10680@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please formulate that is a test case? Use this structure:

1. do this
2. this happens
3. this should happen instead

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:23:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Dec 2010 16:23:32 +0000
Subject: [issue10631] ZipFile and current directory change
In-Reply-To: <1291567761.41.0.659026181219.issue10631@psf.upfronthosting.co.za>
Message-ID: <1292084612.96.0.659012282562.issue10631@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10631>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:32:24 2010
From: report at bugs.python.org (Mads Michelsen)
Date: Sat, 11 Dec 2010 16:32:24 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292085144.33.0.787280353146.issue10680@psf.upfronthosting.co.za>


Mads Michelsen <madchine at gmail.com> added the comment:

Okay, I'll try:

Save the following code as argparse_test.py:

[CODE]
#! /usr/bin/env python2

import argparse

def args_config(about):
    parser = argparse.ArgumentParser(description=about)
    dummy_group = parser.add_argument_group(title='mutually exclusive')
    test_group = dummy_group.add_mutually_exclusive_group()
    test_group.add_argument('-a', action='store_true', default=False, \
        help='This is the r option')
    test_group.add_argument('-b', action='store_true', default=False, \
        help='This is the b option')
    test_group.add_argument('-c', action='store_true', default=False, \
        help='And this is the c option')
    args_ns = parser.parse_args()
    return args_ns

about = 'This is a test case'
args_ns = args_config(about)
print args_ns
[/CODE]

The use the -h argument to see help output:

[OUTPUT]
[~] python/argparse_test.py -h
usage: argparse_test.py [-h] [-a] [-b] [-c]

This is a test case

optional arguments:
  -h, --help  show this help message and exit

mutually exclusive:
  -a          This is the r option
  -b          This is the b option
  -c          And this is the c option
[/OUTPUT]

The run it with all the options together to test exclusivity:

[OUTPUT]
[~] python/argparse_test.py -abc
Namespace(a=True, b=True, c=True)
[/OUTPUT]

What happens: As you can see, there are no objections to using all three options at the same time. Neither does the help output indicate that there should be.

What should happen:
If I have understood the instructions in the Issue report on Google correctly, the assumption is that this workaround (i.e. using a dummy group) should produce the desired result (i.e. that running the command argparse_test.py -abc" should appear as and be prbohibited)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:49:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 16:49:04 +0000
Subject: [issue10642] Improve the error message of addpackage() (site.py) for
	defective .pth file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292086144.98.0.807861871877.issue10642@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: site.py crashes on python startup due to defective .pth file -> Improve the error message of addpackage() (site.py) for defective .pth file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 17:55:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 16:55:05 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292086505.79.0.0204088161059.issue7213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

subprocess-cloexec-atomic-py3k-tests2-close_fds.patch adds a test called to Win32ProcessTestCase which is specific to Windows. And this class has already a test with the same name. You should move your test to ProcessTestCase (and so it will test the C implementation, the Python implementation and also without poll).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:00:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 17:00:21 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292086821.53.0.36461755436.issue7213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> subprocess-cloexec-atomic-py3k-tests2-close_fds.patch adds a test
> called?[test_close_fds] to Win32ProcessTestCase ...

Oops, forget my last comment, I didn't applied the patches in the right order. There are too much patches :-p Can you try to create one unique patch? It will be easier to test it and to review it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:02:37 2010
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Sat, 11 Dec 2010 17:02:37 +0000
Subject: [issue7695] missing termios constants
In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>
Message-ID: <1292086957.15.0.828059526801.issue7695@psf.upfronthosting.co.za>


Rodolpho Eckhardt <r at rhe.vg> added the comment:

Because these constants might not exist on all platforms, the patch uses ifdef's around them.

----------
keywords: +patch
nosy: +Rodolpho.Eckhardt
Added file: http://bugs.python.org/file20015/patch_termios_consts_issue7695.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7695>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:02:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 17:02:57 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292086977.17.0.501061213058.issue7213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

subprocess-cloexec-atomic-py3k.patch:

+case $ac_sys_system in
+  GNU*|Linux*)
+      AC_CHECK_FUNC(pipe2, AC_DEFINE(HAVE_PIPE2, 1, [Define if the OS supports pipe2()]), )
+esac
 
I think that you can remove the test on the OS name. AC_CHECK_FUNC() doesn't hurt if the function doesn't exist. Other OS may have pipe2().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:10:26 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 11 Dec 2010 17:10:26 +0000
Subject: [issue10502] Add unittestguirunner to Tools/
In-Reply-To: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>
Message-ID: <1292087426.53.0.0187628445686.issue10502@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Attaching patch that adds the unittestgui to Tools/scripts.  Also has updates to the unittest documentation which includes a note that this tool is for beginners and a CI system should be used in general.

----------
keywords: +patch
nosy: +MarkRoddy
Added file: http://bugs.python.org/file20016/unittestgui.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10502>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:12:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Dec 2010 17:12:29 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292087549.13.0.236935835658.issue7213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_pipe_cloexec_unix_tools() is specific to UNIX/BSD because it requires cat and grep programs. You should try to reuse the Python interpreter to have a portable test (eg. working on Windows), as you did with fd_status.py.


+        data = b'aaaaaaaaaaaaaaaaaaaa\n'
+        subdata = b'aaa'
+        assert subdata in data, "Test broken"

Use maybe subdata = data[:3] to avoid an assertion.

I don't understand why do you talk about "atomicity". Do you test add non-atomic operations? Was subprocess atomic?

If I understood correctly, you are fixing a specific issue which can be called something like "subprocess: close pipes on exec(), set FD_CLOEXEC flag to all pipes", and no more changing the default value of close_fds. Can you update the title please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:12:50 2010
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sat, 11 Dec 2010 17:12:50 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292087570.29.0.16680308981.issue10188@psf.upfronthosting.co.za>


Jurko Gospodneti? <jurko.gospodnetic at gmail.com> added the comment:

Also this class, because it defines __del__ too simply, will display a user-unfriendly error message when cleaning up a TemporaryDirectory object whose constructor raised an exception when attempting to create its temporary folder.

  For example try to create a TemporaryDirectory with prefix="aa>aa" on Windows. That should fail as folders there can not contain '>' characters and later on in the program you should get an error message something like this one:

Exception AttributeError: "'TemporaryDirectory' object has no attribute '_closed'" in <bound method TemporaryDirectory.cleanup of <tempfile.TemporaryDirectory object at 0x00CE1E10>> ignored

  Hope this helps.

[Sorry, did not know whether to add this as a separate issue as it seemed kind of related to this one.]

----------
nosy: +Jurko.Gospodneti?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sat Dec 11 18:19:47 2010
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sat, 11 Dec 2010 17:19:47 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292087987.33.0.177793536.issue10188@psf.upfronthosting.co.za>


Jurko Gospodneti? <jurko.gospodnetic at gmail.com> added the comment:

Clicked send too soon on the previous comment. :-(

  The simplest way I see you can fix the __del__ issue is to patch TemporaryDirectory.__init__() as follows:

    def __init__(self, suffix="", prefix=template, dir=None):
        self._closed = True
        self.name = mkdtemp(suffix, prefix, dir)
        self._closed = False

  This is based on the tempfile.py from the 3.2 beta 1 release on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:12:59 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 11 Dec 2010 18:12:59 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>


New submission from Phil Thompson <phil at riverbankcomputing.com>:

In Python v3.2b1 the type of the first argument of PySlice_GetIndices() and PySlice_GetIndicesEx() has changed from PySliceObject* to PyObject*.

The documentation does not reflect this change.

Which is correct, the source code or the documentation?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 123809
nosy: Phil.Thompson, docs at python
priority: normal
severity: normal
status: open
title: PySlice_GetIndices() signature changed
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:17:54 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Dec 2010 18:17:54 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292091474.24.0.24636846719.issue10677@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/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:17:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Dec 2010 18:17:54 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292091474.28.0.430709852771.issue10681@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The source is correct. Fixed in r87171.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:18:34 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Dec 2010 18:18:34 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292091514.47.0.184975422942.issue10679@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/issue10679>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:20:07 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Dec 2010 18:20:07 +0000
Subject: [issue10663] configure shouldn't set a default OPT
In-Reply-To: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>
Message-ID: <1292091607.21.0.0386895381711.issue10663@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/issue10663>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:21:48 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 11 Dec 2010 18:21:48 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1292091708.87.0.509417418533.issue969718@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/issue969718>
_______________________________________

From report at bugs.python.org  Sat Dec 11 19:40:49 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 11 Dec 2010 18:40:49 +0000
Subject: [issue7213] Popen.subprocess change close_fds default to True
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292092849.44.0.885255358491.issue7213@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 20:10:31 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 11 Dec 2010 19:10:31 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292094631.68.0.249535499148.issue10681@psf.upfronthosting.co.za>


Phil Thompson <phil at riverbankcomputing.com> added the comment:

You might want to add a "Changed in Python v3.2" because as it is an incompatible change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Sat Dec 11 20:10:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Dec 2010 19:10:50 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292094650.98.0.808780716968.issue10188@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied the fix from msg123808 in r87172.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sat Dec 11 20:23:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Dec 2010 19:23:38 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292095418.32.0.833887657784.issue10681@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's not an incompatible change, but I added the versionchanged anyway in r87173.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Sat Dec 11 20:51:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Dec 2010 19:51:25 +0000
Subject: [issue10642] Improve the error message of addpackage() (site.py) for
	defective .pth file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1292097085.64.0.787210357603.issue10642@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My guess is people don't read warnings when they are a common occurrence.  A working Python should not emit any warnings, and a properly working Python program (post 2.6/3.1 (or whenever it was we decided to suppress deprecation warnings by default)) should not either.  But certainly messages that don't cause program termination *can* be ignored, and thus are more often than program-terminating errors :)

On the other hand, this *is* an error.  If we agree that python startup and site.py should not fail in the face of misconfigured libraries (and we aren't necessarily agreed on that :) then another option would be to use the logging facility to generate an error that would, by default, be logged to stderr but still allow Python to start.  That's not that much different from emitting a warning, functionally, but by having the message make it clear that it is an error it might make it more likely the user would take action.

As for whether or not we should want Python to be able to start up in the face of 3rd party library misconfiguration, I think there are arguments on both sides.  The most compelling argument I can think of for having errors in third partly libraries not cause startup failure is that a user borking their system python by installing a malfunctioning library would then cause all python-dependent system functions to fail to run until they'd fixed the install.  With a system such as gentoo where the package manager that the user might want to use to do the uninstall uses Python, this could be a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 11 22:33:31 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 11 Dec 2010 21:33:31 +0000
Subject: [issue10677] "make altinstall" includes ABI codes in versioned
	executable name
In-Reply-To: <1292067550.81.0.896632970481.issue10677@psf.upfronthosting.co.za>
Message-ID: <1292103211.44.0.800388538481.issue10677@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r87174 moves the creation of the hard link between python-3.2m and python-3.2 from the bininstall target to the altbininstall target.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10677>
_______________________________________

From report at bugs.python.org  Sat Dec 11 22:42:23 2010
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 11 Dec 2010 21:42:23 +0000
Subject: [issue8911] regrtest.main should have a test skipping argument
In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za>
Message-ID: <1292103743.84.0.58320964315.issue8911@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

Hi Tarsis,

I looked at your patch.  It looks like it only does step 1 and doesn't move away from parse_command_line directly modifying sys.argv.  Was this the patch file that you intended to upload?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8911>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:26:09 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:26:09 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106369.86.0.673925197274.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

OK, I have created new updated patches. I haven't combined them in one patch because some of the changes can be applied independently, the three patches can be cat'ed together if anyone sees separate patches a problem. ;)

I. Changes:
* Now pipe2 would be used on all systems where available.
* I don't depend on external grep and cat, but use utils shipped with the tests.

II. The patches:
1. subprocess-00-subprocess_test_utils.patch
This contains the fd_status.py and input_reader.py utilities that are needed by the tests. A separate file because they can be used for creating unit tests for issue 6559. In case these patches aren't accepted, it could be useful there.

2. subprocess-01-atomic_cloexec_pipe2.patch
This file contains the changes that make the subprocess pipes created with the FD_CLOEXEC flag (atomically through pipe2) where possible. Can be used independently of the rest
of the patches.

3. subprocess-02-cloexec_tests.patch
This file contains the tests that verify that CLOEXEC is set on the pipes created by subprocess and this allows complex pipes between apps to work correctly. Requires subprocess-00-subprocess_test_utils.patch. It can be used for another implementation of CLOEXEC in case this implementation isn't accepted. With slight modification it can be used to test that pipes work fine with close_fds=True and no CLOEXEC.

III. Atomicity and issue 2320:

> I don't understand why do you talk about "atomicity". Do you test add non-atomic 
> operations? Was subprocess atomic?
>
> If I understood correctly, you are fixing a specific issue which can be called 
> something like "subprocess: close pipes on exec(), set FD_CLOEXEC flag to all pipes", 
> and no more changing the default value of close_fds. Can you update the title please?

The CLOEXEC flag needs to be set atomically (or at least in a way that another subprocess won't start in the middle of it) so that issue 2320 is also resolved. This is why I suggested the use of pipe2. On systems where pipe2 isn't available, the patches rely on the coincidence that the GIL during both process execution and the pipe creation. I was wondering if a tests that verify for things like issue 2320 are wanted in general (there's no way to reliably test such, but there could be a test that does it with a certain probability).

In short, yes, the suggested patches attempt to solve this issue without a change to the default, but also to resolve issue 2320 (changing the default would also resolve it).

III. More issues:

1. What other possible situations exist causing the same issue that can be solved with close_fds=True and are caused by resources coming from other modules? Are any of those common? Maybe something involving os.openpty() and subprocess? Does anyone use those together? Are such issues worth worrying about (in other words, is changing the default still necessary if the subprocess pipes have the FD_CLOEXEC flag?)
2. What possible side-effects could the FD_CLOEXEC flag have? Any common use-case that is broken by the fact that the pipes are now with FD_CLOEXEC?
3. Can any changes be done to Python 2.7's subprocess? Can the issue be fixed there too, or it will have to remain as it is now?

----------
title: Popen.subprocess change close_fds default to True -> subprocess leaks open file descriptors between Popen instances causing hangs
Added file: http://bugs.python.org/file20017/subprocess-00-subprocess_test_utils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:26:42 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:26:42 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106402.71.0.732094905656.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20018/subprocess-01-atomic_cloexec_pipe2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:27:32 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:27:32 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106452.3.0.663019939736.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20019/subprocess-02-cloexec_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:32:53 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:32:53 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106773.99.0.375708949517.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file20019/subprocess-02-cloexec_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:33:06 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:33:06 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106786.74.0.775292916015.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Added file: http://bugs.python.org/file20020/subprocess-02-cloexec_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:34:43 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:34:43 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106883.79.0.506806400606.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file20005/subprocess-cloexec-atomic-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:34:48 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:34:48 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106888.71.0.0145095264133.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file20009/subprocess-cloexec-atomic-py3k-tests1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sat Dec 11 23:34:53 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 11 Dec 2010 22:34:53 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292106893.36.0.81963472594.issue7213@psf.upfronthosting.co.za>


Changes by Milko Krachounov <python at milko.3mhz.net>:


Removed file: http://bugs.python.org/file20013/subprocess-cloexec-atomic-py3k-tests2-close_fds.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sun Dec 12 00:07:49 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 11 Dec 2010 23:07:49 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292108869.1.0.777840189868.issue7213@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Paul & Giovanni: yes I hadn't given the windows side of things any thought when I made the change for beta1.

Milko: The DISREGARD_FDS approach is basically what I was intending to do.

Also, there really wasn't any objection to going ahead and changing the close_fds default for real in 3.2 assuming the windows issue is addressed.  changing it to your disregard suggestion (true on posix, false on windows) seems to fit peoples needs and keeps the basic usage simple and gets rid of any suggestion that everyone needs to specify true or false for all use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sun Dec 12 00:44:48 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 11 Dec 2010 23:44:48 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292111088.17.0.255808571337.issue2690@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

here is the patch for the py3k docs.

----------
Added file: http://bugs.python.org/file20021/stdtypes.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sun Dec 12 02:38:04 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sun, 12 Dec 2010 01:38:04 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292117884.06.0.876574314269.issue10681@psf.upfronthosting.co.za>


Phil Thompson <phil at riverbankcomputing.com> added the comment:

It's source level incompatible - my extension modules compiled fine with v3.2a but failed with v3.2b1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Sun Dec 12 03:22:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Dec 2010 02:22:16 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292120536.21.0.0775444644537.issue10188@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I have a slightly better fix for that coming soon. There's a subtle race condition in the proposed approach that can lead to the temporary dir not being deleted if an asynchronous exception, such as KeyboardInterrupt, arrives after mkdtemp completes successfully, but before _closed is set back to False.

Instead, the new init code will look like:

        self._closed = False
        self.name = None # Handle mkdtemp throwing an exception
        self.name = mkdtemp(suffix, prefix, dir)

And the cleanup condition will be gated on self.name being set as well as on _closed being False. I believe there is still a window where mkdtemp successfully creates the directory, but self.name never gets set, but we want to make that window as small as possible.

I also realised this should be emitting a ResourceWarning from __del__, as well catching the errors and shut down and turning them into something more meaningful on sys.stderr.

The attached patch won't quite apply cleanly, since it predates r87172

----------
keywords: +patch
Added file: http://bugs.python.org/file20022/issue10888_tempdir_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Dec 12 03:23:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Dec 2010 02:23:16 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292120596.4.0.739731070126.issue10188@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Although it may be better to just raise a new, more meaningul, exception and let the runtime take care of ignoring it (since it happens in __del__)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Dec 12 05:30:02 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 12 Dec 2010 04:30:02 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

Let examples speak:

    def x(a, z): pass      # this is ok
    def x(a, z,): pass     # this is ok
    def x(a, *, z): pass   # this is ok in Py3k
    def x(a, *, z,): pass  # but this causes SyntaxError (!)

    def x(a, *args): pass      # this is ok
    def x(a, *args,): pass     # but this causes SyntaxError
    def x(a, **kwargs): pass   # this is ok
    def x(a, **kwargs,): pass  # but this causes SyntaxError
    def x(a, *args, z): pass   # this is ok in Py3k
    def x(a, *args, z,): pass  # but this causes SyntaxError (!)

And similarly -- calls:

    def x(*args, **kwargs): pass
    x(1, *(2,3,4))        # this is ok
    x(1, *(2,3,4),)       # but this causes SyntaxError
    x(1, **{5: 6})        # this is ok
    x(1, **{5: 6},)       # but this causes SyntaxError
    x(1, 2, 3, 4, z=5)    # this is ok
    x(1, *(2,3,4), z=5)   # this is ok in Py2.6+ and Py3k
    x(1, *(2,3,4), z=5,)  # but this causes SyntaxError (!)

Similar problem was discussed years ago as a docs bug -- see: issue798652, but -- as inconsistent with intuition and a general Python rule that trailing commas are ok in argument lists and sequence literals (except empty ones) -- it seems to be rather a language syntax definition issue.

Now, after introducing new syntax possibilities in Py2.6 and especially Py3k (see the examples above), the issue is even much more painful.

Also, please consider that Py3k's function annotations encourage to format argument list in one-argument-per-line-manner:

    def my_func(
        spam:"Very tasty and nutritious piece of food",
        ham:"For experts only",
        *more_spam:"Not less tasty and not less nutritious!",
        spammish:"Nobody expects this!"='Inquisition',
    ):
        ...

----------
components: Interpreter Core
messages: 123823
nosy: zuo
priority: normal
severity: normal
status: open
title: With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 05:36:05 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 12 Dec 2010 04:36:05 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292128565.07.0.657540459834.issue10682@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

s/**{5: 6}/**{'5': 6}/g (but it's a detail)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 06:02:13 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 12 Dec 2010 05:02:13 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292130133.1.0.255618794583.issue10682@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

Oops, I see the problem was partly addressed @ issue9232.

But:

* the proposed patch doesn't fix calls (but defs only),

* shouldn't be the issue considered as a bug -- and fixed also in 2.7 and 3.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 06:59:09 2010
From: report at bugs.python.org (honglei jiang)
Date: Sun, 12 Dec 2010 05:59:09 +0000
Subject: [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>


New submission from honglei jiang <jhonglei at gmail.com>:

1>PreLinkEvent:
1>  Description: Generate build information...
1>  Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
1>  Copyright (C) Microsoft Corporation.  All rights reserved.
1>  
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD ..\Modules\getbuildinfo.c -Fo"E:\Python-3.2b1\PCbuild\Win32-temp-Release\pythoncore"\getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
1>..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(108,5): error MSB3073: The command ""E:\Python-3.2b1\PCbuild\make_buildinfo.exe" Release "E:\Python-3.2b1\PCbuild\Win32-temp-Release\pythoncore\"
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(108,5): error MSB3073: :VCEnd" exited with code -1.
1>
1>Build FAILED.

the following will be ok:
cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD ..\Modules\getbuildinfo.c -I..\Include -I..\PC -Fo"E:\Python-3.2b1\PCbuild\Win32-temp-Release\pythoncore"\getbuildinfo.o" 

included dir should ahead of -F options.

----------
components: Build
messages: 123826
nosy: honglei.jiang
priority: normal
severity: normal
status: open
title: PreLinkEvent error under VC2010
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10683>
_______________________________________

From report at bugs.python.org  Sun Dec 12 07:01:09 2010
From: report at bugs.python.org (honglei jiang)
Date: Sun, 12 Dec 2010 06:01:09 +0000
Subject: [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292133669.53.0.589664566007.issue10683@psf.upfronthosting.co.za>


Changes by honglei jiang <jhonglei at gmail.com>:


----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10683>
_______________________________________

From report at bugs.python.org  Sun Dec 12 08:35:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 07:35:22 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292117884.06.0.876574314269.issue10681@psf.upfronthosting.co.za>
Message-ID: <4D047B36.7050206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It's source level incompatible - my extension modules compiled fine with v3.2a but failed with v3.2b1.

That's because you are using C++, right? In C, there shouldn't be any
problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Sun Dec 12 08:54:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 07:54:41 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292140481.64.0.104358894505.issue10682@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's clearly not a bug: the documented grammar matches the implemented grammar. Asking for more abstract consistency is a feature request. This also clearly falls under the PEP 3003 moratorium.

----------
nosy: +loewis
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 08:55:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 07:55:34 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292140534.44.0.900231372376.issue9232@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Retargetting, as this falls under the moratorium, and also because 3.2b1 has been released.

----------
nosy: +loewis
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Sun Dec 12 09:04:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 08:04:54 +0000
Subject: [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292141094.58.0.193199885433.issue10683@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The problem is different: there is a stray " in pythoncore"\getbuildinfo.o. Kristjan, this is your change: can you take a look?

----------
nosy: +krisvale, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10683>
_______________________________________

From report at bugs.python.org  Sun Dec 12 09:16:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Dec 2010 08:16:29 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1292141789.67.0.545346770591.issue9922@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Update 31 backport patch to reflect revert of unittest method names prior to 3.1.3 release.

----------
Added file: http://bugs.python.org/file20023/issue9922-31-rev1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Sun Dec 12 09:16:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 12 Dec 2010 08:16:40 +0000
Subject: [issue9922] subprocess.getstatusoutput can fail with utf8
	UnicodeDecodeError
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1292141800.31.0.210397185376.issue9922@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file18972/issue9922-31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Sun Dec 12 11:11:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Dec 2010 10:11:14 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292148674.23.0.241706840783.issue7213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fd_status.py:

+try:
+    _MAXFD = os.sysconf("SC_OPEN_MAX")
+except:
+    _MAXFD = 256

It looks like this code (256 constant) comes from subprocess.py. Is that a good value? On Linux, SC_OPEN_MAX is usually 1024, and it can be 4096. Should we keep the default value 256, or use 1024 or 4096 instead? I don't know on which OS SC_OPEN_MAX is missing.

--

fd_status.py: isopen(fd) uses fcntl.fcntl(fd, fcntl.F_GETFD, 0). Is it always available? If not, we can add fstat() as a fallback. The buildbots will tell us :-)

--

subprocess.py: _create_pipe() doesn't use pipe2() because Python doesn't provide pipe2(). We should maybe add it to the posix module (open maybe a new issue for that).

> The CLOEXEC flag needs to be set atomically (or at least in a way
> that another subprocess won't start in the middle of it)

For the Python implementation, the GIL is not enough to ensure the atomicity of a process creation. That's why _posixsubprocess was created. I suppose that other parts of subprocess are not atomic and a lock is required to ensure that the creation of subprocess is atomic.

--

_posixsubprocess.c: is FD_CLOEXEC flag always available? fcntlmodule.c uses a "#ifdef FD_CLOEXEC".

Can you add a comment to explain why you can release the GIL here? (because the operation is atomic)

+    Py_BEGIN_ALLOW_THREADS
+    res = pipe2(fds, O_CLOEXEC);
+    Py_END_ALLOW_THREADS

--

test_subprocess.py: test_pipe_cloexec() and test_pipe_cloexec_real_tools() should maybe be skipped if fcntl has no attribute FD_CLOEXEC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sun Dec 12 11:18:44 2010
From: report at bugs.python.org (harish)
Date: Sun, 12 Dec 2010 10:18:44 +0000
Subject: [issue10684] Shutil.move deletes file/folder in windows while renaming
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>


New submission from harish <nsharish.mit at gmail.com>:

Shutil.move method deletes a file/folder when the file/folder is renamed to same name but different case.
eg.
shutil.move('folder','Folder')

----------
components: Windows
messages: 123833
nosy: harish
priority: normal
severity: normal
status: open
title: Shutil.move deletes file/folder in windows while renaming
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Sun Dec 12 11:40:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Dec 2010 10:40:16 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292150416.59.0.826124345345.issue9232@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Sun Dec 12 11:41:03 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 12 Dec 2010 10:41:03 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1292150463.83.0.599968135592.issue9344@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch (against the latest revision, 87178) which adds the functionality to the posix module as well as adds a testcase for it.

I haven't added it to the os module, I'm not sure if that should be done.

I tested it on Linux & FreeBSD and it works as expected. Since I don't have an OS X system, I could not test it on there.

----------
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20024/9344.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Sun Dec 12 13:17:29 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 12 Dec 2010 12:17:29 +0000
Subject: [issue10261] tarfile iterator without members caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1292156249.21.0.00590607311534.issue10261@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

There is no trivial or backwards-compatible solution to this problem. The way it is now, there is no alternative to storing all TarInfo objects: there is no central table of contents in an archive we could use, so we must create our own. In other words, tarfile does not "burn" memory without a reason.

The problem you encounter is somehow a corner case, fortunately with a simple workaround:

for tarinfo in tar:
    ...
    tar.members = []

There are two things that I will clearly refuse to do. One thing is to add yet another option to the TarFile class to switch off caching as this would make many TarFile methods dysfunctional without the user knowing why. The other thing is to add an extra non-caching Iterator class.

Sorry, that I have nothing more to offer. Maybe, someone else comes up with a brilliant idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10261>
_______________________________________

From report at bugs.python.org  Sun Dec 12 13:34:30 2010
From: report at bugs.python.org (Rusi)
Date: Sun, 12 Dec 2010 12:34:30 +0000
Subject: [issue10685] trace does nto ignore --ignore-module
In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za>
Message-ID: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za>


New submission from Rusi <rustompmody at gmail.com>:

When running trace, I get a a lot of lines like:
filename: /usr/lib/python2.7/cmd.py, modulename: cmd, funcname: Cmd

That is to say system modules are shown in the trace whereas I only want to see the code I am working on

Ive tried
python2.7 -m trace --listfuncs tt.py --ignore-dir '/usr/lib' > const-dir.trace

python2.7 -m trace --listfuncs --ignore-module cmd tt.py  > const.trace

python2.7 -m trace --ignore-module --listfuncs  cmd tt.py  > const.trace

----------
messages: 123836
nosy: RusiMody
priority: normal
severity: normal
status: open
title: trace does nto ignore --ignore-module
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10685>
_______________________________________

From report at bugs.python.org  Sun Dec 12 14:14:50 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sun, 12 Dec 2010 13:14:50 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292159690.98.0.697297374776.issue7213@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

> For the Python implementation, the GIL is not enough to
> ensure the atomicity of a process creation. That's why 
> _posixsubprocess was created. I suppose that other parts 
> of subprocess are not atomic and a lock is required to
> ensure that the creation of subprocess is atomic.
Both _posixsubprocess.fork_process and _posixsubprocess.cloexec_pipe (without HAVE_PIPE2) hold the GIL. They can't be running at the same time, so in regards to each other, they will be atomic. Or at least that's the idea. You don't need a separate lock when the GIL is already held. Neither a lock nor the GIL make the operation to be atomic (e.g. if someone forks from multiprocessing, the effect might be different, though os.fork() also holds the GIL and I think multiprocessing uses it).

The idea of _posixsubprocess is that fork() isn't thread-safe, because Python might call malloc() or free() in the child, which might be currently locked by another thread, which might cause the child to hang. Nothing to do with atomicity.

> Can you add a comment to explain why you can release the 
> GIL here? (because the operation is atomic)

I release the GIL because I copy-pasted the code from os.pipe(). It makes sense that pipe() and pipe2() are called in the same way. In the other implementation it is held to (ab)use it to avoid the race, but there's no need to hold it here because pipe2() *is* atomic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Sun Dec 12 16:26:52 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Dec 2010 15:26:52 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292167612.22.0.981797979072.issue10188@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Tidy ups committed in r87182. Shutdown problems now result in a slightly more meaningful message on stderr, a ResourceWarning is triggered when an implicit teardown occurs and the chances of an AttributeError due to an exception in __init__ are minimised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Dec 12 17:36:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 16:36:27 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292171787.01.0.150323644172.issue10682@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/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 17:39:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 16:39:47 +0000
Subject: [issue10684] Shutil.move deletes file/folder in windows while renaming
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1292171987.56.0.209854093404.issue10684@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brian.curtin, tarek, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Sun Dec 12 17:48:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 16:48:49 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292172529.1.0.896684028666.issue10188@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The tests are failing on windows:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/3770/steps/test/logs/stdio

======================================================================
ERROR: test_mkdtemp_failure (test.test_tempfile.test_TemporaryDirectory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_tempfile.py", line 933, in test_mkdtemp_failure
    tempfile.TemporaryDirectory(prefix="[]<>?*!:")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\tempfile.py", line 624, in __init__
    self.name = mkdtemp(suffix, prefix, dir)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\tempfile.py", line 301, in mkdtemp
    _os.mkdir(file, 0o700)
WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: 'c:\\docume~1\\db3l\\locals~1\\temp\\[]<>?*!:9ohp4a'

======================================================================
FAIL: test_warnings_on_cleanup (test.test_tempfile.test_TemporaryDirectory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_tempfile.py", line 1001, in test_warnings_on_cleanup
    self.assertIn(d.name,  message)
AssertionError: 'c:\\docume~1\\db3l\\locals~1\\temp\\94ifn5\\ujobx5' not found in 'ERROR: TypeError("\'NoneType\' object is not callable",) while cleaning up <TemporaryDirectory \'c:\\\\docume~1\\\\db3l\\\\locals~1\\\\temp\\\\94ifn5\\\\ujobx5\'>\n'

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Dec 12 17:49:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 16:49:40 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292172580.7.0.203385296175.issue10188@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There's also a typo in the issue number in your commit message (10888 instead of 10188).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Dec 12 18:04:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 17:04:49 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
	with "UnboundLocalError: local variable 'result' referenced
	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1292173489.53.0.532563451003.issue10367@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Sun Dec 12 18:05:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 17:05:15 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1292173515.4.0.767708853822.issue4391@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sun Dec 12 18:39:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 17:39:13 +0000
Subject: [issue1459867] Message.as_string should use "mangle_from_=unixfrom"?
Message-ID: <1292175553.48.0.257192426415.issue1459867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On balance I think this would be a backward incompatible change that has insufficient benefit to be worth doing.  People who have working code will be depending on the existing defaults of the two methods, and changing this out from under them would be unkind.

----------
resolution:  -> wont fix
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1459867>
_______________________________________

From report at bugs.python.org  Sun Dec 12 19:01:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 18:01:49 +0000
Subject: [issue10686] email.Generator should use unknown-8bit encoded words
	for headers with 8 bit data
In-Reply-To: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>
Message-ID: <1292176909.21.0.316774202966.issue10686@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

This is a followon to Issue 4661.  The fix for that issue introduced a way to parse messages containing 8bit bytes.  When Generator is called on a model containing 8 bit bytes, it converts it to 7bit clean.  There is, however, a bug in this conversion process: currently when encountering 8bit bytes in headers, it simply replaces then with ?.  According to the RFCs[*], what it should do instead is to replace them with encoded words using the 'charset' "unknown-8bit".

[*] I'm specifically referring to RFC 1428...email is effectively acting as a translating gateway when requested to do the 8bit to 7bit conversion.  Although that RFC does not explicitly say that the unknown-8bit charset should be used in encoded words, it does imply it strongly in its section 3 prescription.

----------
assignee: r.david.murray
messages: 123842
nosy: r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: email.Generator should use unknown-8bit encoded words for headers with 8 bit data
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10686>
_______________________________________

From report at bugs.python.org  Sun Dec 12 19:03:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 18:03:18 +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: <1292176998.8.0.412678488404.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've opened a issue 10686 to address improving the RFC conformance by using unknown-8bit encoded words for 8bit bytes in headers.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Sun Dec 12 19:08:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 18:08:27 +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: <1292177307.38.0.227378969279.issue4766@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The wording was clarified for 3.2 as part of the fix for issue 4661.  This does not help the 3.1 docs, so if someone wants to suggest a patch for the 3.1 docs we can reopen the issue.

----------
resolution: postponed -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4766>
_______________________________________

From report at bugs.python.org  Sun Dec 12 19:34:05 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 12 Dec 2010 18:34:05 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ make DESTDIR=/var/tmp/portage/dev-lang/python-3.2_pre20101212/image/ altinstall 
Creating directory /usr/bin
Creating directory /usr/lib64
/usr/bin/install -c python /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2
if test -f /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2 -o -h /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2; \
then rm -f /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin/python3.2; \
else true; \
fi
(cd /var/tmp/portage/dev-lang/python-3.2_pre20101212/image//usr/bin; ln python3.2 python3.2)
ln: accessing `python3.2': No such file or directory
make: *** [altbininstall] Error 1

----------
components: Build
messages: 123845
nosy: Arfrever, barry
priority: normal
severity: normal
status: open
title: Python fails to install with empty ABI flags
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10687>
_______________________________________

From report at bugs.python.org  Sun Dec 12 19:55:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 18:55:34 +0000
Subject: [issue10631] ZipFile and current directory change
In-Reply-To: <1291607715.03.0.0685583162794.issue10631@psf.upfronthosting.co.za>
Message-ID: <4D051AA1.2040304@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So, Martin, are you then arguing that this should in fact be
> considered a bug in ZipFile?  The documentation for the constructor
> says "Open a ZIP file, where file can be either a path to a file (a
> string) or a file-like object."  Reading that I would certainly
> expect it to accept a relative path, and for that path to be relative
> to the CWD at the time I called ZipFile, not at the time I called
> extractall.

You have a point here. So I now think that this should be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10631>
_______________________________________

From report at bugs.python.org  Sun Dec 12 20:37:14 2010
From: report at bugs.python.org (Eric Pruitt)
Date: Sun, 12 Dec 2010 19:37:14 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1292182634.28.0.273799991058.issue10634@psf.upfronthosting.co.za>


Changes by Eric Pruitt <eric.pruitt at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Sun Dec 12 20:59:12 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Dec 2010 19:59:12 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292183952.86.0.870488450258.issue10682@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The current behavior for function definitions is beneficial because a trailing comma in the argument list is likely to signal a real error (omitted variable).

In contrast, the trailing comma for lists is useful because entries on separate lines in a repeating pattern that makes it easy to add or remove entries.

The use cases for both function definitions and lists are best served by the current behavior, more so that a notion driven by "foolish consistency".

Recommend rejecting and closing.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 21:30:35 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 12 Dec 2010 20:30:35 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292185835.65.0.659123155778.issue10682@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm with Raymond; this is unneeded consistency. I honestly would rather see what little support there is for a trailing comma to go away, but w/o looking at the grammar I am willing to bet that would be a pain to get right and not be worth the effort.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 21:33:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 20:33:57 +0000
Subject: [issue1243654] Faster output if message already has a boundary
Message-ID: <1292186037.46.0.0688951841598.issue1243654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed a simpler fix in r87196, backported to 3.1 in r87195, and 2.7 in r87196.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1243654>
_______________________________________

From report at bugs.python.org  Sun Dec 12 21:51:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 20:51:11 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292187071.34.0.261976007514.issue10682@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, so closing as rejected.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Sun Dec 12 21:52:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 20:52:58 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292187178.1.0.565835848593.issue9232@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In #10682, several committers indicated that they would prefer not to change this. So I'm closing this as rejected. Per convention, it would probably require a PEP to modify Python in this aspect (as there is no clear consensus).

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Sun Dec 12 22:52:27 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 12 Dec 2010 21:52:27 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1292190747.18.0.879980664468.issue9893@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I just looked at the syntax file linked by Antoine and that is definitely *not* what he meant to link to; probably meant http://www.vim.org/scripts/script.php?script_id=790 . As for the indentation file, it's out-of-date and so doesn't support 'with' statements (looks like people have already started to fork it: http://www.vim.org/scripts/script.php?script_id=3003).

At this point I'm willing to either hand maintenance of the files over to someone else or to delete the files and shift what we point people at.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Sun Dec 12 23:38:45 2010
From: report at bugs.python.org (CZ)
Date: Sun, 12 Dec 2010 22:38:45 +0000
Subject: [issue10688] pydoc removes lib directory
In-Reply-To: <1292193525.59.0.524407556664.issue10688@psf.upfronthosting.co.za>
Message-ID: <1292193525.59.0.524407556664.issue10688@psf.upfronthosting.co.za>


New submission from CZ <huangj at qualcomm.com>:

when pydoc is run with "python -m" (e.g., "python -m pydoc map"),
you will receive an error message: No module named tempfile.

The reason is pydoc removes 'C:\Python26\lib' (in my case) from sys.path.

But you can run it as "python <full path to pydoc.py>" because the lib directory appears twice in the sys.path in such situation.

----------
messages: 123853
nosy: CZ
priority: normal
severity: normal
status: open
title: pydoc removes lib directory
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10688>
_______________________________________

From report at bugs.python.org  Sun Dec 12 23:41:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Dec 2010 22:41:32 +0000
Subject: [issue10688] pydoc removes lib directory
In-Reply-To: <1292193525.59.0.524407556664.issue10688@psf.upfronthosting.co.za>
Message-ID: <1292193692.64.0.343615626514.issue10688@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 2029.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "python -m pydoc -g"  fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10688>
_______________________________________

From report at bugs.python.org  Mon Dec 13 03:09:57 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Dec 2010 02:09:57 +0000
Subject: [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292206197.32.0.60255014712.issue10683@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, I have VC2010 so I'll see what happens...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10683>
_______________________________________

From report at bugs.python.org  Mon Dec 13 03:21:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 02:21:37 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292206897.19.0.183794412944.issue9286@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I've studied this more, and it looks to me like the legacy address format allows multiple atoms separated by white space in the local part of the address.  This means that the correct parse would be

  ('', 'merwok wok at rusty.com')

How useful this parse is is a good question.  It is arguably better than losing the white space; however, the fact that it represents a behavior change and there's no actual user bug against this argues against backport.  I do think it is better to conform to the RFC as much as possible, though, so I'd like to fix this in 3.2.

Attached is a patch to the parser that preserves whitespace runs in between unquoted atoms in the local part.

It would be interesting to know what other email programs do with such addresses.

----------
keywords: +patch
stage:  -> patch review
versions:  -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20025/preserve_unquoted_white_space_in_local_part.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Mon Dec 13 03:22:21 2010
From: report at bugs.python.org (Pierre Vinet)
Date: Mon, 13 Dec 2010 02:22:21 +0000
Subject: [issue10689] _scproxy extension is NOT build
In-Reply-To: <1292206941.33.0.0915401161156.issue10689@psf.upfronthosting.co.za>
Message-ID: <1292206941.33.0.0915401161156.issue10689@psf.upfronthosting.co.za>


New submission from Pierre Vinet <vinp at globetrotter.net>:

>From Python 2.7 http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tar.bz2 released on November 27th, 2010.

At compile time :

 $ ../Python-2.7.1/configure --enable-framework
 $ make

we obtain within standard output:

building '_scproxy' extension
creating build/Python-2.7.1
creating build/Python-2.7.1/Mac
creating build/Python-2.7.1/Mac/Modules
/sw/lib/gcc4.2/bin/gcc -fno-strict-aliasing -fno-common -dynamic -O2 -Wall -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/Python-2.7.1/Mac/Include -I. -IInclude -I../Python-2.7.1/Include -I/sw/include -I/opt/macports/include -I/opt/include -I/usr/X11R6/include -I/usr/include -I/usr/local/include -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/Python-2.7.1/Include -I/Users/vinp/Documents/informatique/python/installation/version-2.7.1/objet_fwk -c ../Python-2.7.1/Mac/Modules/_scproxy.c -o build/temp.macosx-10.3-ppc-2.7/../Python-2.7.1/Mac/Modules/_scproxy.o
../Python-2.7.1/Mac/Modules/_scproxy.c: In function ?get_proxy_settings?:
../Python-2.7.1/Mac/Modules/_scproxy.c:67: error: lvalue required as unary ?&? operand

Then the module _scproxy is not build, which yield to 35 tests crashes:
    test_SimpleHTTPServer test___all__ test_cgi test_codecmaps_cn
    test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_cookielib test_distutils test_email
    test_email_codecs test_email_renamed test_httpservers test_mailbox
    test_mimetypes test_normalization test_old_mailbox test_pyclbr
    test_robotparser test_sax test_site test_smtplib test_smtpnet
    test_ssl test_sundry test_urllib test_urllib2
    test_urllib2_localnet test_urllib2net test_urllibnet test_wsgiref
    test_xml_etree test_xml_etree_c test_xmlrpc

$ uname -a
Darwin ts-77.rmkipqxaas02.globetrotter.net 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

Compiler gcc (GCC) is 4.2.4 (2007)

Thanks,

Pierre Vinet

----------
assignee: ronaldoussoren
components: Build, Macintosh, Tests
messages: 123857
nosy: ronaldoussoren, vinp
priority: normal
severity: normal
status: open
title: _scproxy extension is NOT build
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10689>
_______________________________________

From report at bugs.python.org  Mon Dec 13 03:43:52 2010
From: report at bugs.python.org (Adrian Sampson)
Date: Mon, 13 Dec 2010 02:43:52 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292208232.03.0.727514523058.issue9234@psf.upfronthosting.co.za>


Adrian Sampson <asampson at cs.washington.edu> added the comment:

Thanks for the pointer, ?ric. Here's a quick patch that integrates the same functionality into the existing subparser class.

----------
keywords: +patch
Added file: http://bugs.python.org/file20026/argparse-aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Mon Dec 13 03:53:08 2010
From: report at bugs.python.org (David)
Date: Mon, 13 Dec 2010 02:53:08 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>


New submission from David <mapstonsisiht at yahoo.com>:

Hello, 

Python version 2.7.1 x64
Mac OS X 10.6.5 x86_64
Tk/Tcl version 8.5/4

Python will crash when saving/running/checking a module, i tried googling for a few hours to come up to NOTHING for a solution. Hopefully we can both get this fixed. Thank you.

Attached is a Python crash log.

----------
components: IDLE
files: Python_2010-12-12-214329_Darwin.txt
messages: 123859
nosy: David_Anon
priority: normal
severity: normal
status: open
title: IDLE Crash when running/saving Module
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20027/Python_2010-12-12-214329_Darwin.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 04:13:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 13 Dec 2010 03:13:09 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292209989.66.0.293997775696.issue10188@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sorry, I realised after I had logged off and gone to bed that I hadn't finished the last test. Fixed in r87204 with an approach that should exercise the relevant behaviour regardless of platform.

The commit message has also been updated to refer to the correct issue.

I'm actually going to close this now - the problem of misbehaviour due to modules being nulled out at shutdown is a more universal problem being tracked elsewhere, and I think the behaviour I just added is the best we can hope for until that is fixed.

----------
resolution:  -> fixed
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Mon Dec 13 04:21:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Dec 2010 03:21:06 +0000
Subject: [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292210466.79.0.143750161095.issue10683@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok the problem is this line in the pre-link step, that must have gotten changed during the conversion:
"$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)"
should be
"$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
This is because ($IntDir) will expand to a path ending in a backslash, thus escaping the quotes.  We have to escape the backslash using this notation.
The backslash gets removed during the automatic update of the project files.
Is there an official VS2010 build project?  If there is one, I can fix this there.

There is an alternative.  We can catch this particular error by skiping a trailing " in the path name.  This is perhaps good too, since others are bound to run into this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10683>
_______________________________________

From report at bugs.python.org  Mon Dec 13 04:33:22 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 Dec 2010 03:33:22 +0000
Subject: [issue10683] PreLinkEvent error under VC2010
In-Reply-To: <1292133549.4.0.198657844522.issue10683@psf.upfronthosting.co.za>
Message-ID: <1292211202.81.0.753049726769.issue10683@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Implemented the "trailing quote removal" defensive programming strategy in revision 87205.
Others that autoconvert the solution will not be hit by this problem.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10683>
_______________________________________

From report at bugs.python.org  Mon Dec 13 07:46:06 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 13 Dec 2010 06:46:06 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292222766.57.0.110138913153.issue7213@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The close_fds default has been fixed in r87206 to remove the DeprecationWarning and remain False on Windows.  It changes to True on POSIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Mon Dec 13 09:03:15 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 13 Dec 2010 08:03:15 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292227395.63.0.10042869543.issue7213@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Milko's subprocess-00/01/02 patch set have been committed with minor modifications in r87207 & r87208.  Thanks, especially for the test cases!

Is there anything else left that we know about for this bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Mon Dec 13 09:26:09 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 13 Dec 2010 08:26:09 +0000
Subject: [issue10691] make testall no longer working on Darwin
In-Reply-To: <1292228769.61.0.198684606781.issue10691@psf.upfronthosting.co.za>
Message-ID: <1292228769.61.0.198684606781.issue10691@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k r87206 on Mac OSX 10.6.5,

[~/Sources/py3k]> make testall
running build
running build_ext
building dbm using ndbm

Python build finished, but the necessary bits to build these modules were not found:
_gdbm              ossaudiodev        spwd            
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -E -bb  ./Lib/compileall.py
Traceback (most recent call last):
  File "./Lib/compileall.py", line 223, in <module>
    exit_status = int(not main())
  File "./Lib/compileall.py", line 205, in main
    if os.path.isdir(dest):
  File "/Users/cartman/Sources/py3k/Lib/genericpath.py", line 41, in isdir
    st = os.stat(s)
TypeError: Can't convert 'NoneType' object to str implicitly
make: *** [testall] Error 1

----------
components: Tests
messages: 123865
nosy: cartman
priority: normal
severity: normal
status: open
title: make testall no longer working on Darwin
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10691>
_______________________________________

From report at bugs.python.org  Mon Dec 13 10:18:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Dec 2010 09:18:06 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292231886.43.0.343556393224.issue9234@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.  Can you add tests for the new functionality?  (This is listed in the link I gave you :)

Note: this code

    if 'aliases' in kwargs:
        aliases = kwargs.pop('aliases')
    else:
        aliases = ()

can be shortened to

    aliases = kwargs.pop('aliases', ())

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Mon Dec 13 10:28:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Dec 2010 09:28:42 +0000
Subject: [issue10689] _scproxy extension is NOT build
In-Reply-To: <1292206941.33.0.0915401161156.issue10689@psf.upfronthosting.co.za>
Message-ID: <1292232522.12.0.802794088624.issue10689@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Building Python on OS X is currently only tested and supported using the gcc provided by Apple's Xcode Developer Tools (either gcc-4.0 for building on OS X 10.4 and 10.5 and gcc-4.2 or -4.0 for building on 10.6, depending on deployment target).  Also judging from the file paths shown, you've ended up with a mixture of Fink and MacPorts include file paths before the standard system ones, almost certainly a bad idea. Please reopen if the problem can be reproduced using Apple's gcc-4.0 for 10.4.

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10689>
_______________________________________

From report at bugs.python.org  Mon Dec 13 10:43:59 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Dec 2010 09:43:59 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292233439.61.0.927911006893.issue10690@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Without more specific details on exactly how to reproduce the problem, I assume you are seeing something like the problem reported in Issue9783.  There are several reported problems with IDLEs that are linked with the Apple-supplied Tcl/Tk 8.5 in OS X 10.6.  That includes the current python.org 2.7.1 64-bit installer.  The simplest workaround at the moment is to use the other, 32-bit-only 2.7.1 installer for OS X.  It uses the Apple Tcl/Tk 8.4 or ActiveTcl 8.4, if present, neither of which exhibits these kinds of problems.

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> duplicate
status: open -> pending
superseder:  -> _elementtree.c warnings under 64-bit Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 11:02:53 2010
From: report at bugs.python.org (Giovanni Bajo)
Date: Mon, 13 Dec 2010 10:02:53 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292234573.8.0.93576847893.issue7213@psf.upfronthosting.co.za>


Giovanni Bajo <giovannibajo at gmail.com> added the comment:

Hi Gregory,

will you backport Mirko's patches to subprocess32?

The last thing left in this bug is my proposal to change the default of close_fds to True to Windows too, but at the same time detect whether this is possible or not (depending on the pipe redirections). 

So basically close_fds=True would be changed to mean "close the FDs, if it is possible, otherwise never mind". This is not a break in compatibility on Linux/UNIX (where it is always "possible"), nor Windows (where currently it just raises a ValueError if you ask it to raise close the file descriptors while doing redirections).

The rationale for this change is again cross-compatibility. I don't like when my code breaks because of a limitation of an OS that has a clear workaround. Subprocess is a high-level library after all, it's not like os.fork() or similar low-level libraries which expose the underlying platform differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Mon Dec 13 12:07:46 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Mon, 13 Dec 2010 11:07:46 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292238466.46.0.252104664239.issue9232@psf.upfronthosting.co.za>


Changes by Jan Kaliszewski <zuo at chopin.edu.pl>:


----------
nosy: +zuo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Mon Dec 13 12:48:41 2010
From: report at bugs.python.org (Jari Tenhunen)
Date: Mon, 13 Dec 2010 11:48:41 +0000
Subject: [issue469972] xmlrpclib won't marshal new types
Message-ID: <1292240921.78.0.390197440846.issue469972@psf.upfronthosting.co.za>


Jari Tenhunen <jari.tenhunen at iki.fi> added the comment:

How about revisiting this one? Although this behavior/limitation is documented, it is quite surprising to the user. FWIW, (simple)json module serializes subclasses of builtin types just as expected.

----------
nosy: +jait

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue469972>
_______________________________________

From report at bugs.python.org  Mon Dec 13 13:11:45 2010
From: report at bugs.python.org (Yevgeniy)
Date: Mon, 13 Dec 2010 12:11:45 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>


New submission from Yevgeniy <shchemelevev at gmail.com>:

When i trying to connect to courier-imap server i got error:
"server not IMAP4 compliant"
But as i see in the debug information and server responses there is error in the source code of library.
imaplib.py version: 2.58 
courier-imap server version: 0.91-ubuntu1
os version: ubunto 10.04(lucid)
You can see debug information and telnet session in attached file.
Best regards, Yevgeniy.

----------
components: Library (Lib)
files: debug.txt
messages: 123871
nosy: silversky
priority: normal
severity: normal
status: open
title: imap lib server compabilities
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file20028/debug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Mon Dec 13 13:47:12 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Dec 2010 12:47:12 +0000
Subject: [issue10693] error in documentation of
	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of:

distutils.archive_util.make_zipfile(base_name, base_dir[, verbose=0, dry_run=0]) 

Says:

  Create a zip file from all files in and under base_dir. The output zip file will be named base_dir + .zip. 

This isn't correct, as the name of the output file is "base_name + .zip"

The error exists both in the docstring of make_zipfile in distutils/archive_util.py and in the ReST documentation of the function

----------
assignee: tarek
components: Distutils, Documentation
keywords: easy
messages: 123872
nosy: docs at python, eli.bendersky, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: error in documentation of distutils.archive_util.make_zipfile
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10693>
_______________________________________

From report at bugs.python.org  Mon Dec 13 14:30:25 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 13 Dec 2010 13:30:25 +0000
Subject: [issue469972] xmlrpclib won't marshal new types
Message-ID: <1292247025.97.0.300585391382.issue469972@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

> FWIW, (simple)json module serializes subclasses of builtin types
> just as expected.

Does that round trip properly?  For instance, if you serialize an
instance of a list subclass does it unserialize as a list instance
or as the subclass?

Perhaps JSON has some way of supporting a user-defined set of types.
XML-RPC has no way to do that, and feeding in an instance of a
subtype then getting the base type out on the other end was deemed
a bad thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue469972>
_______________________________________

From report at bugs.python.org  Mon Dec 13 14:46:16 2010
From: report at bugs.python.org (Jari Tenhunen)
Date: Mon, 13 Dec 2010 13:46:16 +0000
Subject: [issue469972] xmlrpclib won't marshal new types
Message-ID: <1292247976.9.0.0604458692887.issue469972@psf.upfronthosting.co.za>


Jari Tenhunen <jari.tenhunen at iki.fi> added the comment:

>> FWIW, (simple)json module serializes subclasses of builtin types
>> just as expected.
> Does that round trip properly?  For instance, if you serialize an
> instance of a list subclass does it unserialize as a list instance
> or as the subclass?

You get a list instance. So, at least without any additional work it does not round trip symmetrically. But IMO this is actually the expected result; subclasses of string should serialize like strings, subclasses of list like lists etc. And when you unserialize those without any additional magic, you get the builtin types, not the subclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue469972>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:28:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:28:24 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250504.54.0.0485293688274.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Updating patch because the assertTestRegexMatches name was updated.

----------
Added file: http://bugs.python.org/file20029/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:28:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:28:59 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250539.98.0.598074568311.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file19989/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:29:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:29:05 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250545.24.0.988920217076.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file20029/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:29:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:29:37 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250577.6.0.398553443635.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file20030/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:32:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:32:04 +0000
Subject: [issue10691] make testall no longer working on Darwin
In-Reply-To: <1292228769.61.0.198684606781.issue10691@psf.upfronthosting.co.za>
Message-ID: <1292250724.61.0.682227799329.issue10691@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure why you would be seeing a test failure on OSX when we aren't seeing it on other platforms, but the cause of the bug is known.  It should be fixed by the last patch attached to issue 10453.  If you could test that patch it would be great, but please comment on that issue; I'm going to close this one as a duplicate.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Add -h/--help option to compileall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10691>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:32:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:32:22 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250742.64.0.757886487733.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +cartman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:34:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:34:00 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250840.97.0.144588233913.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file20030/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:34:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:34:25 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292250865.95.0.193787506625.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file20031/compileall_cli_revisited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:38:43 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Mon, 13 Dec 2010 14:38:43 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292251123.7.0.913842988693.issue10453@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Patch works fine on Mac OSX 10.6.5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Dec 13 15:51:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 14:51:44 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292251904.95.0.301850794514.issue10692@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Where does the non-telnet part of your trace come from?  How did you produce it?  Does this error still occur using 2.7?  (Python 2.6 is in security fix only mode at this point.)

----------
nosy: +eric.smith, r.david.murray
stage:  -> unit test needed
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Mon Dec 13 16:21:26 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Dec 2010 15:21:26 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292253686.38.0.381740892439.issue10687@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Please include your ./configure command too

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10687>
_______________________________________

From report at bugs.python.org  Mon Dec 13 16:22:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Dec 2010 15:22:13 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292253733.88.0.86720084843.issue10188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A test still fails under Windows:

======================================================================
FAIL: test_warnings_on_cleanup (test.test_tempfile.test_TemporaryDirectory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_tempfile.py", line 1003, in test_warnings_on_cleanup
    self.assertIn(d.name,  message)
AssertionError: 'c:\\docume~1\\db3l\\locals~1\\temp\\c2h__k\\1kxw82' not found in 'ERROR: TypeError("\'NoneType\' object is not callable",) while cleaning up <TemporaryDirectory \'c:\\\\docume~1\\\\db3l\\\\locals~1\\\\temp\\\\c2h__k\\\\1kxw82\'>\n'

----------------------------------------------------------------------

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Mon Dec 13 16:42:38 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Dec 2010 15:42:38 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292254958.69.0.965389501113.issue9234@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 on this feature request

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Mon Dec 13 16:58:19 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Dec 2010 15:58:19 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292255899.68.0.839971265825.issue10687@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/issue10687>
_______________________________________

From report at bugs.python.org  Mon Dec 13 17:36:50 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 13 Dec 2010 16:36:50 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1292258210.09.0.623217514971.issue10188@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, yes, I failed to account for the additional string escaping performed by the IO stream. I think I've been bitten by that before, but I always forget since I try to always use forward slashes for paths, even on Windows.

r87212 modifies the test to ensure that failure mode is encountered on non-Windows systems as well and correctly reverses the escaping in the test when reading the message back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Mon Dec 13 17:49:21 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Dec 2010 16:49:21 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292258961.76.0.735174927011.issue10687@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I've tested the following patch with both ./configure --prefix=/tmp/python and ./configure --without-pymalloc --prefix=/tmp/python.  Both seem to work as expected.

Note that this patch fixes a small drive-by bug I found, and it makes editing Makefile.pre.in nicer for Emacsers (without I hope affecting other editor users).

----------
keywords: +patch
Added file: http://bugs.python.org/file20032/10687.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10687>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:19:37 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 13 Dec 2010 17:19:37 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292260777.13.0.613564695864.issue10687@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The patch works correctly for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10687>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:44:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 17:44:54 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292262294.11.0.825642970394.issue10690@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ned, did you mean issue 9763?

----------
nosy: +r.david.murray
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:45:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 17:45:05 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292262305.9.0.499805333214.issue10690@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:48:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 17:48:22 +0000
Subject: [issue10634] Windows timezone changes not reflected by time.localtime
In-Reply-To: <1291593444.74.0.0494991149013.issue10634@psf.upfronthosting.co.za>
Message-ID: <1292262502.12.0.731218788851.issue10634@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage: unit test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10634>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:52:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Dec 2010 17:52:57 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292262777.79.0.648402192881.issue10690@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

[updated to refer to correct issue - thanks!]

Without more specific details on exactly how to reproduce the problem, I assume you are seeing something like the problem reported in Issue9763.  There are several reported problems with IDLEs that are linked with the Apple-supplied Tcl/Tk 8.5 in OS X 10.6.  That includes the current python.org 2.7.1 64-bit installer.  The simplest workaround at the moment is to use the other, 32-bit-only 2.7.1 installer for OS X.  It uses the Apple Tcl/Tk 8.4 or ActiveTcl 8.4, if present, neither of which exhibits these kinds of problems.

----------
status: pending -> open
superseder: _elementtree.c warnings under 64-bit Windows -> Crashes upon run after syntax error encountered in OSX 10.5.8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:53:24 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Dec 2010 17:53:24 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292262804.92.0.695425849353.issue10690@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg123868

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 18:53:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Dec 2010 17:53:57 +0000
Subject: [issue10690] IDLE Crash when running/saving Module
In-Reply-To: <1292208787.46.0.425889720507.issue10690@psf.upfronthosting.co.za>
Message-ID: <1292262837.82.0.943149728132.issue10690@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10690>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:01:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 18:01:17 +0000
Subject: [issue2394] [Py3k] Finish the memoryview object implementation
In-Reply-To: <1205855988.24.0.314040259236.issue2394@psf.upfronthosting.co.za>
Message-ID: <1292263277.71.0.25593224038.issue2394@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It looks to me like the critical parts of this have been done, so I'm downgrading the priority.

----------
nosy: +r.david.murray
priority: critical -> high
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2394>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:04:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Dec 2010 18:04:55 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292263495.13.0.572040743201.issue10687@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for testing it!  r87213

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10687>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:06:28 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 13 Dec 2010 18:06:28 +0000
Subject: [issue10687] Python fails to install with empty ABI flags
In-Reply-To: <1292178845.71.0.0485366537198.issue10687@psf.upfronthosting.co.za>
Message-ID: <1292263588.42.0.464909688833.issue10687@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10687>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:36:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 18:36:32 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1292265392.09.0.656032107747.issue6302@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Drat, missed this one when I was reviewing my issues for feature requests because I didn't change the type :(

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6302>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:36:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 18:36:50 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1292265410.26.0.0344930754889.issue6302@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6302>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:37:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 18:37:41 +0000
Subject: [issue6302] Add decode_header_as_string method to email.utils
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1292265461.03.0.706555032066.issue6302@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: email.header.decode_header data types are inconsistent and incorrectly documented -> Add decode_header_as_string method to email.utils
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6302>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:48:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Dec 2010 18:48:17 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <4D02B206.4060905@v.loewis.de>
Message-ID: <AANLkTik1kD10MKEcsHZUYEcMMq4z1L2FG6M3WikM2zEV@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Dec 10, 2010 at 6:04 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
>> Why? ?I thought "release early, release often" was a good thing.
>
> Create a branch for that, or post an issue on Rietveld.

Martin,

This is a documentation patch affecting a single HTML page.  An svn
branch for something like this is certainly an overkill.  Maybe when
branches become more user-friendly with Hg, it will make sense to do
something like this in a branch.   Rietveld is great for code reviews,
but for doc patches its is sometimes desirable to post a rendered page
for a review.  In this particular case, however the reST in diff is
quite readable.

> W-I-P IMO
> confuses people reviewing the patches, running into the same ones
> over-and-over again, only to find out every time "it's not ready yet".

I posted this patch with a specific question: "how much of the Unicode
Standard information we would want to present?"   The patch included
several tables similar to what a determined reader can find at
unicode.org.   I think it is useful to present this information in the
Python docs for several reasons:

1. It makes the information more readily accessible to someone who
just want to figure out what the code returned by
unicodedata.category() means.

2. We can present examples using Python notation and focus on what is
relevant to Python users.  For example, what are the digits other than
0-9, or what is the difference between a digit and a decimal.

3. Other parts of the documentation can refer to this information more
easily.  For example, str.isdigit() can refer to 'Nd' general
category.

The downside is that we may need to update this info when Unicode
Standard changes.  Given the pace of change for this info, I don't
think this is serious burden and most of the data can be
auto-generated from UCD files.

> So the natural reaction is to close it as rejected, for it being
> incomplete.

Are you going to reject say issue2636 on this basis? :-)   Has *any*
patch ever been rejected as incomplete?

Seriously, I had a specific reason to post an incomplete patch for
review: formatting reST tables is tedious and if others think we
should not include this info in Python docs, I don't want to spend
more time polishing the patch.  On the other hand, an incomplete patch
is helpful because it demonstrates how much information I am proposing
to include.  If I just posted a request without a patch, a natural
reaction would be: do you have a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:57:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Dec 2010 18:57:47 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1292266667.22.0.848870348585.issue2636@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> patch review
type: compile error -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Dec 13 19:57:51 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Mon, 13 Dec 2010 18:57:51 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>


New submission from Kevin Hendricks <kevin.hendricks at sympatico.ca>:

The current version of zipfile.py is not robust to slight errors at the end of zip archives.  Many file servers **improperly** append a new line to the end of files that do not have a new line when they are uploaded from a browser.  This bug ends up adding 0x0d 0xa to the end of the zip archive.  This in turn makes zipfile.py eventually throw a "Not a zip file" exception when no other zip tools seem to have trouble with them.  Even unzip -t passes these "problem" zip archives with flying colours.

I hate to have to extract and create my own zipfile.py script just to be robust to zip archives that are commonly found on the net and that are handled more robustly by other software.

So please consider changing this code from _EndRecData below to simply ignore any trailing data after the proper stringEndArchive and structEndArchive are found instead of looking for the comment and verifying if the comment is properly formatted and throwing an exception if not correct.  Ignoring the "comment" seems to be more robust in this case as everything needed to unpack the zip archive has been found.


    # Either this is not a ZIP file, or it is a ZIP file with an archive
    # comment.  Search the end of the file for the "end of central directory"
    # record signature. The comment is the last item in the ZIP file and may be
    # up to 64K long.  It is assumed that the "end of central directory" magic
    # number does not appear in the comment.
    maxCommentStart = max(filesize - (1 << 16) - sizeEndCentDir, 0)
    fpin.seek(maxCommentStart, 0)
    data = fpin.read()
    start = data.rfind(stringEndArchive)
    if start >= 0:
        # found the magic number; attempt to unpack and interpret
        recData = data[start:start+sizeEndCentDir]
        endrec = list(struct.unpack(structEndArchive, recData))
        comment = data[start+sizeEndCentDir:]
        # check that comment length is correct
        if endrec[_ECD_COMMENT_SIZE] == len(comment):
            # Append the archive comment and start offset
            endrec.append(comment)
            endrec.append(maxCommentStart + start)
            if endrec[_ECD_OFFSET] == 0xffffffff:
                # There is apparently a "Zip64 end of central directory"
                # structure present, so go look for it
                return _EndRecData64(fpin, start - filesize, endrec)
            return endrec


This will in turn make the Python implementation of zipfile.py more robust to data improperly appended when some zip archives are uploaded or downloaded (similar to how other zip tools handle this issue).

Thank you for your time and consideration.

----------
messages: 123891
nosy: KevinH
priority: normal
severity: normal
status: open
title: zipfile.py end of central directory detection not robust
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:02:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 19:02:27 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1292266947.87.0.76934511584.issue9012@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Bump.  This bug has priority high and it sounds like the patch is ready for commit.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:10:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 19:10:16 +0000
Subject: [issue10340] asyncore doesn't properly handle EINVAL on OSX
In-Reply-To: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>
Message-ID: <1292267416.18.0.165196595521.issue10340@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:12:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 19:12:20 +0000
Subject: [issue10340] asyncore doesn't properly handle EINVAL on OSX
In-Reply-To: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>
Message-ID: <1292267540.69.0.91660912002.issue10340@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"Might even make sense" to backport doesn't sound like a definite, so I've removed 2.6 and 2.5 from versions.  You'll want to ask the release managers for a decision if you want to backport.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:27:10 2010
From: report at bugs.python.org (Christian S. Perone)
Date: Mon, 13 Dec 2010 19:27:10 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>


New submission from Christian S. Perone <christian.perone at gmail.com>:

When you use telnetlib with a "str" parameter as Port Number:
tel = telnetlib.Telnet("10.0.2.9", "8123")
tel.read_until("login: ")

It works fine, except if you set the debuglevel:
tel.set_debuglevel(30)

Then the follow exception is thrown:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python26\lib\telnetlib.py", line 306, in read_until
    self.fill_rawq()
  File "c:\python26\lib\telnetlib.py", line 517, in fill_rawq
    self.msg("recv %r", buf)
  File "c:\python26\lib\telnetlib.py", line 239, in msg
    print 'Telnet(%s,%d):' % (self.host, self.port),
TypeError: %d format: a number is required, not str

I think that the string "Telnet(%s,%d):" on the telnetlib.py should be "Telnet(%s,%s):", since it works fine with a str as Port Number.

----------
components: Library (Lib)
messages: 123894
nosy: Christian.S..Perone
priority: normal
severity: normal
status: open
title: telnetlib.Telnet port number int/str inconsistency
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:29:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Dec 2010 19:29:41 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1292268581.13.0.183673441254.issue9012@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> it sounds like the patch is ready for commit.

there are two pending patches here:

time.diff - a hack that makes _time.c look like a module while it is not.

add_time_to_vc8_build.diff - a patch for VC 8.0 project file.

I don't like time.diff because it fixes the symptom rather than the core problem.  I believe the code that is shared between C modules should be segregated into a true module which would expose its C API via capsule mechanism.  Others suggested that this is an overkill and that capsule mechanism is not suitable for the stdlib.  On the latter argument, I would like to point that unicodedata already uses capsule mechanism to make itself available to Python's builtin str type.

As I mentioned in msg109219, this situation is not unique to time/datetime.  The math and cmath modules similarly use linker tricks to share code in _math.c.

Unassigning because I don't have an informed opinion on add_time_to_vc8_build.diff and cannot move the _time.c issue forward until similar problem is solved for _math.c which I used as the basis for _time.c design.

----------
assignee: belopolsky -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9012>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:32:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Dec 2010 19:32:10 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1292268730.92.0.848902797191.issue6075@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ned.deily
nosy: +ned.deily
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Mon Dec 13 20:59:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Dec 2010 19:59:23 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292270363.64.0.931240921508.issue9232@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> In #10682, several committers indicated that they would prefer
> not to change this.

Issue #10682 has been open for less than 24 hours before it was rejected. In contrast, this issue was open after an almost week-long discussion on python-dev where the proposal was well received.

I think #10682 should have been closed as a duplicate of this issue and this issue should be marked as "after moratorium".

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:05:48 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:05:48 +0000
Subject: [issue10696] port not split in function urllib.parse.urlsplit
In-Reply-To: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>
Message-ID: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>


New submission from JTMoon79 <jtm.moon.forum.user+python at gmail.com>:

urlsplit function from urllib.parse.urlsplit does not return the port field.
Repro steps

>>> import urllib
>>> import urllib.parse
>>> urllib.parse.urlsplit(r'http://foo.bar.com:80/blarg?a=1&b=2')
RETURNS:
SplitResult(scheme='http', netloc='foo.bar.com:80', path='/blarg', query='a=1&b=2', fragment='')
EXPECTED:
SplitResult(scheme='http', netloc='foo.bar.com', path='/blarg', port='80', query='a=1&b=2', fragment='')

----------
components: Library (Lib)
messages: 123897
nosy: JTMoon79
priority: normal
severity: normal
status: open
title: port not split in function urllib.parse.urlsplit
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10696>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:17:20 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:17:20 +0000
Subject: [issue10697] port not split in function urllib.parse.urlparse
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>


New submission from JTMoon79 <jtm.moon.forum.user+python at gmail.com>:

Copy of issue 10696
This issue is exactly the same as issue 10696 except it affects a different function, urllib.parse.urlparse (instead of urllib.parse.urlsplit).

urlparse function from urllib.parse.urlparse does not return the port field.
REPRO STEPS:
>>> import urllib
>>> import urllib.parse
>>> urllib.parse.urlparse(r'http://foo.bar.com:80/blarg?a=1&b=2')
RETURNS:
ParseResult(scheme='http', netloc='foo.bar.com:80', path='/blarg', params='', query='a=1&b=2', fragment='')
EXPECTED: 
ParseResult(scheme='http', netloc='foo.bar.com', path='/blarg', port='80', params='', query='a=1&b=2', fragment='')
END REPRO

The documentation at http://docs.python.org/py3k/library/urllib.parse.html#urllib.parse.urlsplit shows this as expected.  What is the purpose of a possible port parameter if that port parameter is not set?

According to RFC 1808 the syntatic components are 
<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
However, according to referenced RFC 1738 (referenced by RFC 1808)
http://tools.ietf.org/html/rfc1738#section-3.1
the <net_loc> can be further separated to <host> and <port>.

I guess a bigger more general complaint about this is, why not make urlparse more useful by separating <host> and <port>?
I imagine this is a common need of users.  I like standards.  And doing a little extra to work with standards make those standards even more useful.

----------
components: Library (Lib)
messages: 123898
nosy: JTMoon79
priority: normal
severity: normal
status: open
title: port not split in function urllib.parse.urlparse
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10697>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:18:49 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:18:49 +0000
Subject: [issue10696] port not split in function urllib.parse.urlsplit
In-Reply-To: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>
Message-ID: <1292271529.32.0.727816117415.issue10696@psf.upfronthosting.co.za>


JTMoon79 <jtm.moon.forum.user+python at gmail.com> added the comment:

see comments at http://bugs.python.org/issue10697#msg123898

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10696>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:21:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 20:21:27 +0000
Subject: [issue10696] port not split in function urllib.parse.urlsplit
In-Reply-To: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>
Message-ID: <1292271687.74.0.242524548028.issue10696@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Take another look at the documentation.

http://docs.python.org/dev/library/urllib.parse.html

>>> import urllib.parse
>>> o = urllib.parse.urlsplit("http://foo.bar.com:80/blarg?a=1&b=2")
>>> o
SplitResult(scheme='http', netloc='foo.bar.com:80', path='/blarg', query='a=1&b=2', fragment='')
>>> o.port
80

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10696>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:21:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 20:21:33 +0000
Subject: [issue10696] port not split in function urllib.parse.urlsplit
In-Reply-To: <1292270748.56.0.94944870348.issue10696@psf.upfronthosting.co.za>
Message-ID: <1292271693.95.0.55393215268.issue10696@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10696>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:30:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 20:30:46 +0000
Subject: [issue10697] host and port attributes not documented well in function
	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292272246.93.0.323397223006.issue10697@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The repr gives the primary components defined by the URL.  The subfields are provided as attributes of the result.  This is documented in the example at the top of the chapter, but it is not, IMO, well documented in the rest of the chapter.

I'm not sure when this feature was introduced, so I'm leaving 3.1 in the versions for now.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, orsenthil, r.david.murray
stage:  -> needs patch
title: port not split in function urllib.parse.urlparse -> host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10697>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:36:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 20:36:59 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292272619.14.0.219023884182.issue10695@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:43:44 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 13 Dec 2010 20:43:44 +0000
Subject: [issue10697] host and port attributes not documented well in function
	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292272246.93.0.323397223006.issue10697@psf.upfronthosting.co.za>
Message-ID: <AANLkTik5AF1Z-qemeekWNvT0E8fBd5udNHYZv=9Qw5dc@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

These attributes were added in Python 2.5.

Documentation improvements should be backported to 2.7 and 3.1.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10697>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:44:25 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 13 Dec 2010 20:44:25 +0000
Subject: [issue10697] host and port attributes not documented well in function
	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292273065.89.0.961128226953.issue10697@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10697>
_______________________________________

From report at bugs.python.org  Mon Dec 13 21:48:40 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:48:40 +0000
Subject: [issue10697] host and port attributes not documented well in function
	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292273320.3.0.621697909597.issue10697@psf.upfronthosting.co.za>


JTMoon79 <jtm.moon.forum.user+python at gmail.com> added the comment:

Doh!  I feel a bit silly.
I didn't notice 'hostname' and 'port' in 
>>> dir(urllib.parse.urlparse(r'http://foo.bar.com:80/blarg?a=1&b=2'))
[... 'count', 'fragment', 'geturl', 'hostname', 'index'
, 'netloc', 'params', 'password', 'path', 'port', 'query', 'scheme', 'username']

I agree, some clarity in the documentation for these overlapping fields (<net_loc>,<port>,<hostname>) would help.

-J_Tom_Moon_79

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10697>
_______________________________________

From report at bugs.python.org  Mon Dec 13 22:38:56 2010
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 13 Dec 2010 21:38:56 +0000
Subject: [issue10698] doctest load_tests() typo
In-Reply-To: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>
Message-ID: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

doctest.html Section 24.2.5 "Unittest API" says:


def load_tests(loader, tests, ignore):
    tests.addTests(doctest.DocTestSuite(my_module_with_doctests))
    return test

That last line should be "return tests"

----------
assignee: docs at python
components: Documentation
messages: 123904
nosy: dalke, docs at python
priority: normal
severity: normal
status: open
title: doctest load_tests() typo
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10698>
_______________________________________

From report at bugs.python.org  Mon Dec 13 22:53:15 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Mon, 13 Dec 2010 21:53:15 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1292277195.69.0.921068028924.issue10618@psf.upfronthosting.co.za>


Changes by Mads Kiilerich <mads at kiilerich.com>:


----------
nosy: +kiilerix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10618>
_______________________________________

From report at bugs.python.org  Mon Dec 13 23:26:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Dec 2010 22:26:56 +0000
Subject: [issue10665] Expand unicodedata module documentation
In-Reply-To: <AANLkTik1kD10MKEcsHZUYEcMMq4z1L2FG6M3WikM2zEV@mail.gmail.com>
Message-ID: <4D069DAD.7020909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Are you going to reject say issue2636 on this basis? :-)   Has *any*
> patch ever been rejected as incomplete?

I certainly did close patches for that reason. Before that, I keep
asking people not to post W-I-P. As for issue2636, I have been really
tempted to, see msg83277, msg83411. In one case, the conversation ended
with the user being banned from the tracker. I personally feel fairly
strongly that it is abuse to post things that you know are incomplete.
I won't review any such code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10665>
_______________________________________

From report at bugs.python.org  Mon Dec 13 23:42:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Dec 2010 22:42:43 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292280163.73.0.364683589942.issue9232@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I stand by my evaluation: there is clearly no consensus about this change, so it certainly requires more discussion, potentially leading to proponents being asked to write a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Mon Dec 13 23:51:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 22:51:17 +0000
Subject: [issue10698] doctest load_tests() typo
In-Reply-To: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>
Message-ID: <1292280677.29.0.072428687553.issue10698@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  Fixed in r87216.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10698>
_______________________________________

From report at bugs.python.org  Tue Dec 14 00:07:12 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Mon, 13 Dec 2010 23:07:12 +0000
Subject: [issue10699] [patch] fix incorrect help doc with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

The following patch fixes the help docstring as time.tzset when called doesn't require any arguments (as noted in the source and also in the library documentation).

The patch produced was against trunk, but this appears to be an issue on release-maint26 and release-maint27 (and the patch applies cleanly) as the text is the same.

----------
assignee: docs at python
components: Documentation
files: fix-timemodule-helpdoc.patch
keywords: patch
messages: 123908
nosy: docs at python, yaneurabeya
priority: normal
severity: normal
status: open
title: [patch] fix incorrect help doc with time.tzset
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20033/fix-timemodule-helpdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10699>
_______________________________________

From report at bugs.python.org  Tue Dec 14 00:56:35 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 13 Dec 2010 23:56:35 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292284595.12.0.321478722743.issue9232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

An open issue more accurately reflects the lack of consensus than a closed one, though. We just won't commit it until there *is* consensus that it is a better option than the status quo.

----------
keywords: +after moratorium -patch
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Dec 14 00:57:44 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 13 Dec 2010 23:57:44 +0000
Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, 
	trailing comma causes SyntaxError
In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za>
Message-ID: <1292284664.95.0.771309753711.issue10682@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution: rejected -> duplicate
superseder:  -> Allow trailing comma in any function argument list.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10682>
_______________________________________

From report at bugs.python.org  Tue Dec 14 00:59:23 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 13 Dec 2010 23:59:23 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292284763.02.0.30190451552.issue9232@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

>From 10682: the grammar is also inconsistent as to when trailing commas are allowed in function calls, not just definitions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Dec 14 01:30:25 2010
From: report at bugs.python.org (Adrian Sampson)
Date: Tue, 14 Dec 2010 00:30:25 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292286625.85.0.0939194775866.issue9234@psf.upfronthosting.co.za>


Adrian Sampson <asampson at cs.washington.edu> added the comment:

Sorry I'm slow. Here's a new patch that includes tests. I'll also write documentation if that would be helpful, although I'm not very familiar with the style recommendations.

----------
Added file: http://bugs.python.org/file20034/argparse-aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Tue Dec 14 01:30:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 00:30:59 +0000
Subject: [issue1078919] email.Header (via add_header) encodes non-ASCII
	content incorrectly
Message-ID: <1292286659.37.0.545916405864.issue1078919@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed the default-to-utf8 fix in r87217, splitting up the tests as suggested by Barry.  Backported to 3.1 in r87218.  Updated the documentation for 2.7 in r87219.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1078919>
_______________________________________

From report at bugs.python.org  Tue Dec 14 01:34:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Dec 2010 00:34:32 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292286872.23.0.826641138292.issue9234@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the quick update!

+                1 (1alias1,1alias2)
I think there should be a space after the comma.  Maybe ?aliases:? could also be prepended, for clarity.

Help about the docs: http://docs.python.org/dev/documenting/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Tue Dec 14 01:57:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 00:57:44 +0000
Subject: [issue10699] [patch] fix incorrect help doc with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292288264.71.0.545081605436.issue10699@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  Fixed in py3k in r87221.  I'll backport it when I backport my other doc updates.

FYI, 'trunk' is no longer a live branch.  Development trunk is now py3k.  2.6 only gets security fixes.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.1 -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10699>
_______________________________________

From report at bugs.python.org  Tue Dec 14 01:58:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 00:58:01 +0000
Subject: [issue10699] fix incorrect help doc with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292288281.57.0.13581620862.issue10699@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: [patch] fix incorrect help doc with time.tzset -> fix incorrect help doc with time.tzset

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10699>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:10:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 14 Dec 2010 01:10:11 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292289011.1.0.460768513892.issue9232@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/issue9232>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:14:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 01:14:03 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1292289243.48.0.299639699771.issue2226@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> unit test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:37:21 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 14 Dec 2010 01:37:21 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292290641.23.0.531010489441.issue9232@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

>From 10682: The patch proposed in this (#9232) issue does not fix call syntax but def sytax only. I think it should fix call sytax as well (see code examples in #10682).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:43:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 01:43:23 +0000
Subject: [issue9162] License for multiprocessing files
In-Reply-To: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>
Message-ID: <1292291003.9.0.196259055697.issue9162@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r87225, r87226, and r87227.  Thanks, Daniel.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9162>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:44:23 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 14 Dec 2010 01:44:23 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292291063.88.0.449533564599.issue9232@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

python-dev discussion continuation: http://mail.python.org/pipermail/python-dev/2010-December/106770.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:49:59 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 14 Dec 2010 01:49:59 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1292291399.04.0.0529306160981.issue9232@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:54:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 01:54:03 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1292291643.08.0.139567542572.issue9775@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> unit test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9775>
_______________________________________

From report at bugs.python.org  Tue Dec 14 02:56:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 01:56:56 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1292291816.21.0.518225496961.issue6696@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6696>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:16:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:16:14 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1292292974.47.0.612270237872.issue3657@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The randomly failing tests seem to have been the high priority issue.  The remaining, eponymous issue seems to be of rather lower priority, so I'm setting it to normal.  Although Tim wanted a separate issue for the pickling problem, I think there's too much useful info about the underlying problem in this issue for it to make sense to open a new one.

----------
assignee: nnorwitz -> 
nosy: +r.david.murray
priority: high -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3657>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:32:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:32:28 +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: <1292293948.79.0.900643317451.issue4180@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4180>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:37:14 2010
From: report at bugs.python.org (Yevgeniy)
Date: Tue, 14 Dec 2010 02:37:14 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292294234.7.0.268985795245.issue10692@psf.upfronthosting.co.za>


Yevgeniy <shchemelevev at gmail.com> added the comment:

>Where does the non-telnet part of your trace come from?  How did you produce it?
When i got this error i set Debug = 5 in imaplib.py
and run next code:
import imaplib
M = imaplib.IMAP4_SSL('localhost')
M.login('username', 'password')
M.logout()

>Does this error still occur using 2.7?
Yes

As i see in debug information: CAPABILITIES: ('0', 'ACL', 'ACL2=UNION')
but in the telnet session i see next answer:
* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS LOGINDISABLED
Because of this i think that we have maybe some kind of error in the source code of library.
p.s. sorry for my English )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:41:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:41:50 +0000
Subject: [issue6377] distutils compiler switch ignored
In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za>
Message-ID: <1292294510.24.0.0452940417272.issue6377@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +eric.araujo
stage:  -> unit test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6377>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:43:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:43:00 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1292294580.99.0.347760470798.issue6721@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> unit test needed
type:  -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:45:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:45:35 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1292294735.35.0.0294943504778.issue10541@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:49:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:49:18 +0000
Subject: [issue6559] add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1292294958.65.0.414562386888.issue6559@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: [PATCH]add pass_fds paramter to subprocess.Popen() -> add pass_fds paramter to subprocess.Popen()
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Tue Dec 14 03:55:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:55:30 +0000
Subject: [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1292295330.59.0.954805718451.issue10670@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This feature request should be submitted to the Sphinx tracker, since the docs search facility is provided by Sphinx.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10670>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:07:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:07:38 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292296058.41.0.912020285868.issue10692@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, in that case your telnet session doesn't tell us all that much, since you are using IMAP4_SSL in the Python but regular non-SSL in the telnet session.  Are you sure it is even the same server running on the SSL port?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:11:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:11:10 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292296270.37.0.7763168751.issue10692@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By the way, an SSL login runs just fine for me against my Courier-IMAP server.  Does regular IMAP work for you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:13:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:13:47 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292296427.51.0.89558809416.issue8863@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:14:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:14:02 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292296442.65.0.958449651736.issue8863@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:19:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:19:47 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1292296787.12.0.00915931193867.issue10262@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What's the status of this?  It sounds like it something that should be taken care of before the 3.2 release, but I know there has been other activity in this area and I haven't looked closely enough to understand the issues involved.

----------
nosy: +r.david.murray
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:21:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:21:07 +0000
Subject: [issue10530] distutils2 should allow the installing of python files
	with invalid syntax
In-Reply-To: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>
Message-ID: <1292296867.77.0.480991176989.issue10530@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10530>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:26:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 03:26:28 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1292297188.03.0.740640449113.issue6731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Tue Dec 14 04:49:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Dec 2010 03:49:49 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1292298589.73.0.440470519864.issue2226@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Yes, if you have a chance to think it through, it would be nice to get this fixed-up.

----------
assignee:  -> stutzbach
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Tue Dec 14 06:04:56 2010
From: report at bugs.python.org (HwidongNa)
Date: Tue, 14 Dec 2010 05:04:56 +0000
Subject: [issue10700] python pickle.dumps AssertionError
In-Reply-To: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>
Message-ID: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>


New submission from HwidongNa <leona at postech.ac.kr>:

I'm trying to pickle a class instance containing two lists of another instances. The instances in the two lists have attributes that refer instances of each other. Here are the classes.

import pickle
from copy import copy

class Graph:
    def __init__(self):
        self.vertices = {}
        self.edges = set()
    def __repr__(self):
        return "\n".join(map(str, sorted(self.vertices, key=lambda v:v.id)))

class Edge:
    def __init__(self, vfrom, vto):
        self.vfrom = vfrom
        self.vto = vto
    def __hash__(self):
        return hash((self.vto, self.vfrom))
    def __repr__(self):
        return str(self.vto.id)
    def __getstate__(self):
        vfrom = copy(self.vfrom)
        vfrom.del_outgoing(self)
        vto = copy(self.vto)
        vto.del_incoming(self)
        self.__dict__.update({"vfrom":vfrom, "vto":vto, })
        return self.__dict__
    def __setstate__(self, state):
        self.__dict__.update(state)
        self.__dict__["vfrom"].add_outgoing(self)
        self.__dict__["vto"].add_incoming(self)

class Vertex:
    def __init__(self, id):
        self.id = id
        self.incoming = set()
        self.outgoing = set()
    def __repr__(self):
        return "Vertex %d -> %s"%(self.id, ", ".join(map(str, self.outgoing)))
    def __hash__(self):
        return hash(self.id)
    def add_incoming(self, edge):
        if not edge in self.incoming:
            self.incoming.add(edge)
    def add_outgoing(self, edge):
        if not edge in self.outgoing:
            self.outgoing.add(edge)
    def del_incoming(self, edge):
        self.incoming.discard(edge)
    def del_outgoing(self, edge):
        self.outgoing.discard(edge)

I got an AssertionError when I pickled a simple graph as follows.

>>> v0 = Vertex(0)
>>> v1 = Vertex(1)
>>> e0to1 = Edge(v0, v1)
>>> v0.add_outgoing(e0to1)
>>> v1.add_incoming(e0to1)
>>> g = Graph()
>>> g.vertices[v0] = v0
>>> g.vertices[v1] = v1
>>> g.edges.add(e0to1)
>>> g.edges.add(e0to1)
>>> v2 = Vertex(2)
>>> e0to2 = Edge(v0, v2)
>>> v0.add_outgoing(e0to2)
>>> v2.add_incoming(e0to2)
>>> g.vertices[v2] = v2
>>> g.edges.add(e0to2)
>>> 
>>> print g
Vertex 0 -> 2, 1
Vertex 1 -> 
Vertex 2 -> 
>>> p = pickle.dumps(g)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/lib/python2.6/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 725, in save_inst
    save(stuff)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.6/pickle.py", line 663, in _batch_setitems
    save(v)
  File "/usr/lib/python2.6/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.6/pickle.py", line 401, in save_reduce
    save(args)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 562, in save_tuple
    save(element)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 600, in save_list
    self._batch_appends(iter(obj))
  File "/usr/lib/python2.6/pickle.py", line 615, in _batch_appends
    save(x)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 725, in save_inst
    save(stuff)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.6/pickle.py", line 663, in _batch_setitems
    save(v)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 725, in save_inst
    save(stuff)
  File "/usr/lib/python2.6/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.6/pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.6/pickle.py", line 663, in _batch_setitems
    save(v)
  File "/usr/lib/python2.6/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.6/pickle.py", line 405, in save_reduce
    self.memoize(obj)
  File "/usr/lib/python2.6/pickle.py", line 244, in memoize
    assert id(obj) not in self.memo
AssertionError

I worked when the v2 is removed. 

>>> v0 = Vertex(0)
>>> v1 = Vertex(1)
>>> e0to1 = Edge(v0, v1)
>>> v0.outgoing.add(e0to1)
>>> v1.incoming.add(e0to1)
>>> g = Graph()
>>> g.vertices[v0] = v0
>>> g.vertices[v1] = v1
>>> g.edges.add(e0to1)
>>> g.edges.add(e0to1)
>>> import cPickle as pickle
>>> p = pickle.dumps(g)
>>> print pickle.loads(p)
Vertex 0 -> 1
Vertex 1 -> 

Do you have any idea?

----------
components: Library (Lib)
messages: 123925
nosy: Leo.Na
priority: normal
severity: normal
status: open
title: python pickle.dumps AssertionError
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10700>
_______________________________________

From report at bugs.python.org  Tue Dec 14 06:32:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 05:32:13 +0000
Subject: [issue10700] python pickle.dumps AssertionError
In-Reply-To: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>
Message-ID: <1292304733.62.0.72992711255.issue10700@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This looks like another duplicate of issue1062277.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10700>
_______________________________________

From report at bugs.python.org  Tue Dec 14 06:41:12 2010
From: report at bugs.python.org (Yevgeniy)
Date: Tue, 14 Dec 2010 05:41:12 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292305272.4.0.357974929906.issue10692@psf.upfronthosting.co.za>


Yevgeniy <shchemelevev at gmail.com> added the comment:

> By the way, an SSL login runs just fine for me against my Courier-IMAP server.  Does regular IMAP work for you?
No it dose not.
When i run:
M = myimaplib.IMAP4(host)
M.login(username, password)
I got "error: STARTTLS required"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Tue Dec 14 10:30:00 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 14 Dec 2010 09:30:00 +0000
Subject: [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1292319000.58.0.563857303634.issue10670@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

label:interop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10670>
_______________________________________

From report at bugs.python.org  Tue Dec 14 12:28:42 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 14 Dec 2010 11:28:42 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1292326122.29.0.554016907282.issue5863@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Sorry, I'm giving up.

The copyright notice for bz2module.c lists "Gustavo Niemeyer" as one of the holders, is he the maintainer? Maybe he should be notified of this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Dec 14 12:47:23 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 14 Dec 2010 11:47:23 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292327243.05.0.346316212552.issue10695@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Alternatively, I think we can do a conversion to int in Telnet.__init__ (see patch)

----------
keywords: +patch
nosy: +xuanji
Added file: http://bugs.python.org/file20035/issue10695.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 12:50:37 2010
From: report at bugs.python.org (Christian S. Perone)
Date: Tue, 14 Dec 2010 11:50:37 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292327437.34.0.12184012572.issue10695@psf.upfronthosting.co.za>


Christian S. Perone <christian.perone at gmail.com> added the comment:

I don't know, by doing this on __init__ we can break a lot of legacy codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 12:52:28 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 14 Dec 2010 11:52:28 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292327548.24.0.344346583458.issue10694@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi, I would like to take a look at whether your code works, can you provide an zip file that is currently not read by zipfile but should be?

Also, I suggest you submit the code changes as a patch (http://www.python.org/dev/patches/)

thanks!

----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 14 12:53:08 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 14 Dec 2010 11:53:08 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292327588.2.0.555747101247.issue10695@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi, is there any legacy code that would rely on "port" being stored as a string rather than an integer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 12:55:31 2010
From: report at bugs.python.org (Christian S. Perone)
Date: Tue, 14 Dec 2010 11:55:31 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292327731.78.0.173526309075.issue10695@psf.upfronthosting.co.za>


Christian S. Perone <christian.perone at gmail.com> added the comment:

Not from Python itself I think, but external, from users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 13:51:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 12:51:26 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292331086.47.0.0915271946377.issue10695@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, for backward compatibility reasons it is better to make the change that fixes the thing that doesn't work and leave the rest alone.  Probably the change wouldn't break *much* existing user code, but why break anything when there doesn't seem to be any particular advantage to doing so?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 13:58:23 2010
From: report at bugs.python.org (Christian S. Perone)
Date: Tue, 14 Dec 2010 12:58:23 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292331503.92.0.771627158887.issue10695@psf.upfronthosting.co.za>


Christian S. Perone <christian.perone at gmail.com> added the comment:

Agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:38:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 13:38:37 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1292326122.29.0.554016907282.issue5863@psf.upfronthosting.co.za>
Message-ID: <1292333911.3693.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sorry, I'm giving up.

Indeed, I think only an extensive rewrite could fulfill the feature
request here.

> The copyright notice for bz2module.c lists "Gustavo Niemeyer" as one
> of the holders, is he the maintainer? Maybe he should be notified of
> this bug.

He hasn't been active for years, so I don't think he can still be
considered the maintainer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:45:00 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Dec 2010 13:45:00 +0000
Subject: [issue6559] add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1292334300.0.0.193667763366.issue6559@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Bug fix, unittest and documentation added in r87229.  Thanks!

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:45:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 13:45:56 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292334356.76.0.0285265629038.issue10692@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Starttls support was only added in Python 3.2.  Apparently your server is set to disallow non-SSL connections.

Have you confirmed that the same server is listening on port 993 as is listening on port 143?  The debug info from imaplib makes it look like different capability information is being returned, though the banner does look the same.

Please run the regular IMAP4 test with debug on, I think it may be getting past the capabilities query before it produces the starttls error, and if so it would be interesting to compare the two debug traces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:46:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 13:46:16 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292334376.02.0.724243490649.issue10692@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:48:09 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Dec 2010 13:48:09 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292334489.02.0.633626028473.issue7213@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I updated the documentation and changed the close_fds default on Windows to be True when possible per Giovanni's suggestion in r87229.  That keeps the API and defaults as consistent as possible across all platforms.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:48:52 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Dec 2010 13:48:52 +0000
Subject: [issue7213] subprocess leaks open file descriptors between Popen
	instances causing hangs
In-Reply-To: <1256598842.47.0.00127578716198.issue7213@psf.upfronthosting.co.za>
Message-ID: <1292334532.23.0.598555316025.issue7213@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

P.S.  Yes I will be backporting all of this to subprocess32.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7213>
_______________________________________

From report at bugs.python.org  Tue Dec 14 14:49:50 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 14 Dec 2010 13:49:50 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1292334590.75.0.270003695209.issue10262@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

shouldn't that option work on platforms too, which currently default to not using the soabi?  It would make sense for all posix, and macos, maybe not for Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:20:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 Dec 2010 14:20:34 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1292336434.03.0.0743488350783.issue10262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The soabi tag could be useful on Windows as well, for example if some package maintainer chooses another version of the compiler, or a custom version of MSVCRT.

And FWIW, PyPy currently uses "--soabi=pypy-1.4" on all platforms: "import foo" will load foo.pypy-14.so (foo.pypy-14.pyd on Windows). There are also some specific abiflags. A difference is that PyPy will also ignore the default foo.so, because extension modules built for CPython will likely crash with PyPy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:36:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 14:36:45 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292337405.02.0.988364324468.issue10695@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in py3k in r87230, with test.  Backported to 3.1 in r87231 and 2.7 in r87232.  The 2.7 backport doesn't include the test since the test infrastructure for it doesn't exist in the 2.7 test_telnetlib.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:37:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 14:37:20 +0000
Subject: [issue10695] telnetlib.Telnet port number int/str inconsistency
In-Reply-To: <1292268429.73.0.383087651932.issue10695@psf.upfronthosting.co.za>
Message-ID: <1292337440.11.0.0848624632042.issue10695@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10695>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:38:05 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 Dec 2010 14:38:05 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1292337485.74.0.961595956378.issue10262@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Amaury, did you see my suggestion re $SOBASE and $SOEXTRA?

Also, do you think you can write some tests, even if they only run on a single platform?

I suspect the Makefile.pre.in part of the patch will have to be updated now.

Please be sure to test your changes with --enable-shared as well to make sure everything gets installed correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:40:00 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Dec 2010 14:40:00 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1292337600.9.0.473180675538.issue1731717@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r87233 fixes the OSError escaping from wait() issue when SIGCLD is set to be ignored.  (to appear in 3.2beta1; it is a candidate for backporting to 3.1 and 2.7)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:45:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 14:45:34 +0000
Subject: [issue10700] python pickle.dumps AssertionError
In-Reply-To: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>
Message-ID: <1292337934.56.0.866476621624.issue10700@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is a known problem. See issues #1062277 and #9269.  You can work around the issue by using a dict.  I am attaching two test files. First, set-graph.py, reproduces the issue in 3.x and the second, dict-graph.py, contains a workaround.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Cannot pickle self-referencing sets
type: crash -> behavior
Added file: http://bugs.python.org/file20036/set-graph.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10700>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:45:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 14:45:52 +0000
Subject: [issue10700] python pickle.dumps AssertionError
In-Reply-To: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>
Message-ID: <1292337952.29.0.380922981189.issue10700@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file20037/dict-graph.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10700>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:53:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 14:53:56 +0000
Subject: [issue10701] Error pickling a dict
In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za>
Message-ID: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The work-around that I proposed for issue10700 does not work with Python 2.x:

$ python2.7 dict-graph.py
Vertex 0 -> 2, 1
Vertex 1 -> 
Vertex 2 -> 
Traceback (most recent call last):
  File "dict-graph.py", line 74, in <module>
    p = pickle.dumps(g)
    ...
File ".../Lib/pickle.py", line 661, in _batch_setitems
    for k, v in items:
RuntimeError: dictionary changed size during iteration

----------
files: dict-graph.py
messages: 123948
nosy: Leo.Na, belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Error pickling a dict
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20038/dict-graph.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10701>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:54:40 2010
From: report at bugs.python.org (Martin Budaj)
Date: Tue, 14 Dec 2010 14:54:40 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292338480.91.0.956615825543.issue10515@psf.upfronthosting.co.za>


Martin Budaj <m.budaj at gmail.com> added the comment:

> What do you mean by "there is a test for this case in csv.py"?  

I meant test in regex on line 217 in python 2.7 and the following code (line 258ff):

# there is *no* delimiter, it's a single column of quoted data
delim = ''
skipinitialspace = 0

However, it is intended to detect just lines starting and ending with quotes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Tue Dec 14 15:55:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 14:55:28 +0000
Subject: [issue10700] python pickle.dumps AssertionError
In-Reply-To: <1292303096.18.0.227107282365.issue10700@psf.upfronthosting.co.za>
Message-ID: <1292338528.93.0.791651571414.issue10700@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It turns out that dict-graph.py does not work with python2.x, but that is a different problem, so I opened a separate issue for it.  See issue10701.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10700>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:17:06 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Dec 2010 15:17:06 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1292339826.85.0.504358269737.issue1731717@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

sorry, i meant 3.2beta2 above.
release27-maint: r87234 targeting 2.7.2
release31-maint: r87235 targeting 3.1.4

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:19:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 15:19:51 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1292339991.25.0.650954385847.issue10541@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is a simpler invocation that produces a similar error:

$ ./python.exe -m test.regrtest -T  test_trace test_pkg
...

IOError: [Errno 2] No such file or directory: '/var/folders/qs/qsqFUI2xFUKG+9CTf4z7pU+++TI/-Tmp-/tmpy1iyp7/t4/sub/__init__.py'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:22:25 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Tue, 14 Dec 2010 15:22:25 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292340145.68.0.367764013338.issue10694@psf.upfronthosting.co.za>


Kevin Hendricks <kevin.hendricks at sympatico.ca> added the comment:

If you read the bug report it explains how to generate a testcase (i.e. append any data to the end of a zip archive)

Here it is as a step by step process 

1. simply take any working zip and call it testcase.zip 

2. do the following:

echo "\r\n" >> testcase.zip 

If you run "unzip -t" on testcase.zip it will pass with flying colors and will properly unzip on every piece of zip software I have tried.

However if you try to use python to copy the zip archive to another zip archive

python ./zipfix.py testcase.zip junk.zip
Error Occurred  File is not a zip file

All because of the appended carriage return / linefeed at the end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:34:24 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Tue, 14 Dec 2010 15:34:24 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292340864.52.0.98971095846.issue10694@psf.upfronthosting.co.za>


Kevin Hendricks <kevin.hendricks at sympatico.ca> added the comment:

Here is one potential patch.  It simply incorporates and non-comment extraneous data into a final comment so that nothing is lost.  Another solution that might be safer, would be to truncate the zip archive immediately after the endrec is found if the extraneous data is not a properly formatted comment.  The right solution is obviously up to the developers of zipfile.py

--- zipfile_orig.py	2010-12-14 10:23:58.000000000 -0500
+++ zipfile.py	2010-12-14 10:30:21.000000000 -0500
@@ -228,6 +228,13 @@
                 # structure present, so go look for it
                 return _EndRecData64(fpin, start - filesize, endrec)
             return endrec
+        else :
+            # be robust to non-comment extaneous data after endrec
+            # by making it a comment so that nothing is ever lost
+            endrec[_ECD_COMMENT_SIZE] = len(comment)
+            endrec.append(comment)
+            endrec.append(maxCommentStart + start)
+            return endrec
 
     # Unable to find a valid end of central directory structure
     return

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:42:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 15:42:17 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1292341337.1.0.503200318795.issue10587@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that expands the documentation of isalnum, isalpha, isdecimal, isdigit, isnumeric, islower, isupper, and isspace.  I did not change isidentifier or isprintable because their docs were already complete.  I also left out istitle because I could not figure out how to deal with the  confusion between Python and Unicode notions of titlecase.

I would also like to note that it appears that isdigit and isdecimal imply isnumeric, so s.isalnum() is equivalent to all(c.isalpha() or c.isnumeric() for c in s).  However the actual code does have redundant checks for isdecimal() and isdigit().  I think the documentation should reflect what the code does for an off-chance that someone would replace unicodedata with their own database with which these checks are not redundant.

----------
assignee: docs at python -> belopolsky
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file20039/issue10587.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10587>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:43:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 15:43:20 +0000
Subject: [issue7183] did 2.6.3 regress for some uses of the __doc__ property?
In-Reply-To: <1256167357.49.0.413782567423.issue7183@psf.upfronthosting.co.za>
Message-ID: <1292341400.25.0.14224591171.issue7183@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since boost has changed their code and no one else has reported a problem and 2.6 is now in bug fix only mode, I'm going to close this as out of date (sorry I overlooked it for 2.6.5).  

If anyone disagrees, let me know what we should change and why in 2.7.

----------
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Tue Dec 14 16:59:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 15:59:09 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1292342349.39.0.540480361613.issue1731717@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems the canonical spelling is SIGCHLD. SIGCLD doesn't exist everywhere and it produces test failures under OS X:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x

FWIW, this is what POSIX says:

?Some implementations, including System V, have a signal named SIGCLD, which is similar to SIGCHLD in 4.2 BSD. POSIX.1 permits implementations to have a single signal with both names. POSIX.1 carefully specifies ways in which conforming applications can avoid the semantic differences between the two different implementations. The name SIGCHLD was chosen for POSIX.1 because most current application usages of it can remain unchanged in conforming applications. SIGCLD in System V has more cases of semantics that POSIX.1 does not specify, and thus applications using it are more likely to require changes in addition to the name change.?

http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Tue Dec 14 17:00:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 16:00:26 +0000
Subject: [issue6559] add pass_fds paramter to subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1292342426.78.0.176100329022.issue6559@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems there are (intermittent?) test failures:

======================================================================
FAIL: test_pass_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_subprocess.py", line 1067, in test_pass_fds
    "fd to be closed passed")
AssertionError: {5} is not False : fd to be closed passed

======================================================================
FAIL: test_pass_fds (test.test_subprocess.ProcessTestCasePOSIXPurePython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_subprocess.py", line 1067, in test_pass_fds
    "fd to be closed passed")
AssertionError: {5} is not False : fd to be closed passed

(from http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2337/steps/test/logs/stdio )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________

From report at bugs.python.org  Tue Dec 14 17:26:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 16:26:50 +0000
Subject: [issue775964] fix test_grp failing when NIS entries present
Message-ID: <1292344010.21.0.795300854777.issue775964@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r87238, 3.1 in r87239, and 2.7 in r87240.  Thanks, Bobby.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Tue Dec 14 18:07:44 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Tue, 14 Dec 2010 17:07:44 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292346464.9.0.786567383287.issue10694@psf.upfronthosting.co.za>


Changes by Kevin Hendricks <kevin.hendricks at sympatico.ca>:


----------
keywords: +patch
versions: +Python 2.5, Python 2.6
Added file: http://bugs.python.org/file20040/more_robust.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 14 18:26:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 17:26:04 +0000
Subject: [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Library reference manual has a section dedicated to string methods [1], but similar methods of bytes and bytearray types are not documented.  Adding two new sections would probably be too repetitious, so I wonder if it would make sense to add notes about byte/bytearray methods to the matching string methods' entries.  See also issue10587.

[1] http://docs.python.org/dev/py3k/library/stdtypes.html#string-methods

----------
assignee: docs at python
components: Documentation
messages: 123960
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: bytes and bytearray methods are not documented
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10702>
_______________________________________

From report at bugs.python.org  Tue Dec 14 18:41:57 2010
From: report at bugs.python.org (Steve Moran)
Date: Tue, 14 Dec 2010 17:41:57 +0000
Subject: [issue10703] Regex 0.1.20101210
In-Reply-To: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>
Message-ID: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>


New submission from Steve Moran <stiv at uw.edu>:

The regex package doesn't seem to correctly implement the single grapheme match "\X" (\P{M}\p{M}*) for pre-Python 3. I'm using the string "?i-te" (i, U+0301, i, -, t, e -- where U+0301 is Unicode COMBINING ACUTE ACCENT), reading it in from a file to bypass Unicode c&p issues in the older IDLEs). 


stiv at x$ python3.1
Python 3.1.2 (r312:79147, May 19 2010, 11:50:28) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import regex
>>> file = open("test_data", "rt", encoding="utf-8")
>>> s = file.readline()
>>> print (s)
?i-te
>>> print (g.findall(s))
['?', 'i', '-', 't', 'e']

* Correct in 3.1 - i+U+0301 considered one grapheme.

stiv at x$ python2.7
Python 2.7 (r27:82500, Oct  4 2010, 14:49:53) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs                                
>>> import regex
>>> file = codecs.open("test_data", "r", "utf-8")
>>> g = regex.compile("\X")
>>> s = file.readline()
>>> s
u'i\u0301i-te'
>>> print s.encode("utf-8")
?i-te
>>> print g.findall(s)
[u'i', u'\u0301', u'i', u'-', u't', u'e']

*Not correct -- accent is treated as a separate character.

Thanks.

----------
components: Regular Expressions
messages: 123961
nosy: stiv
priority: normal
severity: normal
status: open
title: Regex 0.1.20101210
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10703>
_______________________________________

From report at bugs.python.org  Tue Dec 14 18:50:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 17:50:34 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1292349034.78.0.0186369727258.issue4236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Brett applied his doc patch in r69092.  Attached is a patch that combines Simon's patch with Martin's test program turned into a unit test.  I confirm that the test suite passes with the patch applied (and fails with just the test applied).

>From the text of the original error message, I wonder if there is some way to trigger this error at interpreter startup, and if so whether or not that is tested by the test suite.

Otherwise, is there any reason not to apply this patch?

----------
nosy: +r.david.murray
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20041/check-import-machinery-only-with-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Tue Dec 14 18:58:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 17:58:38 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1292349518.28.0.909713867702.issue3080@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

With #1342 fixed, it seems that this issue is no longer critical (Haypo describes his complicated patch as "useful on Windows", but not critical.  So I'm downgrading it to 'high'.  Perhaps it is even 'normal'.  It also seems as though it is currently languishing unless someone wants to pick it up.

----------
nosy: +r.david.murray
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Tue Dec 14 18:59:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Dec 2010 17:59:34 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292349574.39.0.201551340773.issue8040@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:08:58 2010
From: report at bugs.python.org (Steve Moran)
Date: Tue, 14 Dec 2010 18:08:58 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>


New submission from Steve Moran <stiv at uw.edu>:

Package doesn't want to install on Mac OS X 10.6.5 with Python 3.1 using instructions "python3.1 setup.py install" (or "sudo python3.1 setup.py install").

Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.4u.sdk

Extended error log attached.

NB: I realize this package is in dev and it's got less than 50 current downloads. Thought I'd post anyway. I appreciate any input. Xcode is installed v 3.2.2. 64-bit.

----------
components: Installation
files: regex-0.1.20101210-python31-install-error
messages: 123964
nosy: stiv
priority: normal
severity: normal
status: open
title: Regex 0.1.20101210 Python 3.1 install problem Mac OS X 10.6.5
versions: Python 3.1
Added file: http://bugs.python.org/file20042/regex-0.1.20101210-python31-install-error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:09:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 18:09:59 +0000
Subject: [issue10703] Regex 0.1.20101210
In-Reply-To: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>
Message-ID: <1292350199.82.0.109880985613.issue10703@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Regex 0.1.20101210 is not part of the standard Python distribution, so this bug report is invalid.

----------
nosy: +belopolsky
resolution:  -> invalid
status: open -> closed
superseder:  -> Regexp 2.7 (modifications to current re 2.2.2)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10703>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:12:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 18:12:12 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292350332.98.0.546112680993.issue10704@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Regex 0.1.20101210 is not part of the standard Python distribution, so this bug report is invalid.  See issue2636 for the development status of regex.

----------
nosy: +belopolsky
resolution:  -> invalid
status: open -> closed
superseder:  -> Regexp 2.7 (modifications to current re 2.2.2)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:27:58 2010
From: report at bugs.python.org (Steve Moran)
Date: Tue, 14 Dec 2010 18:27:58 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350332.98.0.546112680993.issue10704@psf.upfronthosting.co.za>
Message-ID: <alpine.LRH.2.01.1012141027210.6326@homer01.u.washington.edu>


Steve Moran <stiv at uw.edu> added the comment:

Yeah, it's not immediately clear how to bring this up at

http://bugs.python.org/issue2636

On Tue, 14 Dec 2010, Alexander Belopolsky wrote:

>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> Regex 0.1.20101210 is not part of the standard Python distribution, so this bug report is invalid.  See issue2636 for the development status of regex.
>
> ----------
> nosy: +belopolsky
> resolution:  -> invalid
> status: open -> closed
> superseder:  -> Regexp 2.7 (modifications to current re 2.2.2)
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10704>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:32:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Dec 2010 18:32:32 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292351552.73.0.632488402246.issue10667@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a new patch for high-speed update() and __init__().  I also tried a C version of __missing__() but the speed-up was too small to be worth it.

----------
resolution: later -> 
stage:  -> patch review
versions: +Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20043/fastcount.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:32:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:32:39 +0000
Subject: [issue10703] Regex 0.1.20101210
In-Reply-To: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>
Message-ID: <1292351559.6.0.376071987998.issue10703@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson, mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10703>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:34:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:34:52 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292351692.27.0.579131568501.issue10704@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:38:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:38:46 +0000
Subject: [issue5368] curses patch add color_set and wcolor_set ,
	and addchstr family of functions
In-Reply-To: <1235583031.0.0.493464972804.issue5368@psf.upfronthosting.co.za>
Message-ID: <1292351926.94.0.99637667011.issue5368@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5368>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:41:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:41:06 +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: <1292352066.64.0.208195720426.issue8769@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:45:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:45:54 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1292352354.54.0.760253355215.issue4402@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like it is "won't fix", since it hasn't been.  It doesn't seem as though it is our responsibility to clean up crud in the windows registry introduced by other distributions.

----------
assignee: loewis -> 
nosy: +r.david.murray
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:50:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 18:50:01 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <alpine.LRH.2.01.1012141027210.6326@homer01.u.washington.edu>
Message-ID: <AANLkTinrTymqNT3-ZKO1OP7LZjq7_SqJ=tRsYy9zhs7=@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Dec 14, 2010 at 1:27 PM, Steve Moran <report at bugs.python.org> wrote:
..
> Yeah, it's not immediately clear how to bring this up at
>
> http://bugs.python.org/issue2636
>

This is the URL listed as the home page for regex 0.1.20101210 on PyPI
[1], so I assume the author(s) will be listening.  You can also
contact the author directly:

Matthew Barnett <regex at mrabarnett plus com>

[1] http://pypi.python.org/pypi/regex/0.1.20101210

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:54:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:54:06 +0000
Subject: [issue8127] Add link to PortingPythonToPy3k to What's
	New	documentation
In-Reply-To: <1268420523.24.0.572888394804.issue8127@psf.upfronthosting.co.za>
Message-ID: <1292352846.58.0.0460658541915.issue8127@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Raymond, I'm adding you as nosy even though I'm closing the issue as out of date in case you do want to add a link in the 3.2 What's New.

----------
nosy: +r.david.murray, rhettinger
resolution:  -> out of date
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8127>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:58:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:58:30 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1292353110.56.0.106602524161.issue8776@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Tue Dec 14 19:59:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 18:59:10 +0000
Subject: [issue9967] encoded_word regular expression in
	email.header.decode_header()
In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>
Message-ID: <1292353150.67.0.0688499363563.issue9967@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9967>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:02:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:02:31 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1292353351.12.0.608919373901.issue8828@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8828>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:05:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:05:55 +0000
Subject: [issue9285] A decorator for cProfile and profile modules
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1292353555.29.0.96903050889.issue9285@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: collinwinter -> 
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:07:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:07:02 +0000
Subject: [issue9248] multiprocessing.pool: Proposal: "waitforslot"
In-Reply-To: <1279028823.93.0.963356654708.issue9248@psf.upfronthosting.co.za>
Message-ID: <1292353622.89.0.347531688689.issue9248@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9248>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:07:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:07:37 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1292353657.25.0.0476683613728.issue9216@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:11:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:11:19 +0000
Subject: [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1292353879.18.0.885584249928.issue9048@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks to Steven Hansen there are now OSX buildbots in the stable list.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9048>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:14:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:14:08 +0000
Subject: [issue4506] 3.0 make test failures on Solaris 10
In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local>
Message-ID: <1292354048.39.0.0527903931064.issue4506@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Are there any open problems left here or can this bug be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4506>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:15:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:15:29 +0000
Subject: [issue1525919] email package quoted printable behaviour changed
Message-ID: <1292354129.7.0.586676278357.issue1525919@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1525919>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:22:43 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 19:22:43 +0000
Subject: [issue10705] HTTPConnection.set_debuglevel has no information about
	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>


New submission from J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com>:

Function HTTPConnection.set_debuglevel(level)
There is no range of acceptable debug levels.
What should be the difference in set_debuglevel(1) and set_debuglevel(1000)?
If the documentation lists the levels this would save users from needing to do tedious trial-error experimentation.

From
http://docs.python.org/py3k/library/http.client.html#http.client.HTTPConnection.set_debuglevel

----------
assignee: docs at python
components: Documentation
messages: 123974
nosy: JTMoon79, docs at python
priority: normal
severity: normal
status: open
title: HTTPConnection.set_debuglevel has no information about level range
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10705>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:37:38 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 14 Dec 2010 19:37:38 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292355458.67.0.22505328004.issue10704@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I use Windows XP, so I can't help with MacOS X.

>From the error log it looks like it doesn't like the sources for Python either!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:44:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:44:13 +0000
Subject: [issue10705] HTTPConnection.set_debuglevel has no information about
	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292355853.83.0.375482288639.issue10705@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Or, since this is Python, they could look at the code and find out that all levels above zero are equivalent.  (If I had to guess I'd say 'level' was either future proofing or designed for the use of subclasses).

But you are right, this should be mentioned in the documentation.  Care to propose a patch?

----------
nosy: +r.david.murray
type:  -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10705>
_______________________________________

From report at bugs.python.org  Tue Dec 14 20:47:28 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 14 Dec 2010 19:47:28 +0000
Subject: [issue10703] Regex 0.1.20101210
In-Reply-To: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>
Message-ID: <1292356048.22.0.813686928575.issue10703@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The regex module is intended to replace the re module, so its default behaviour is the same: in Python 2, regexes default to matching ASCII, and in Python 3, they default to matching Unicode.

If you want to use a regex on a Unicode string in Python 2 then you need to set the Unicode flag, either by providing the UNICODE flag or by putting "(?u)" in the regex itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10703>
_______________________________________

From report at bugs.python.org  Tue Dec 14 22:21:14 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Dec 2010 21:21:14 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1292361674.49.0.160655579469.issue4236@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Nothing jumps to my mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Tue Dec 14 22:32:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 21:32:19 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1292362339.08.0.209160634231.issue8106@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Tue Dec 14 22:57:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 21:57:52 +0000
Subject: [issue10706] kill runtests.sh
In-Reply-To: <1292363871.99.0.211094833748.issue10706@psf.upfronthosting.co.za>
Message-ID: <1292363871.99.0.211094833748.issue10706@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

There are two official ways to run tests:
- "make test" for beginners
- "./python -m test [etc.]" for experts

runtests.sh serves no useful purpose and had completely outdated reporting, making it potentially confusing for newcomers who would try to test it. I therefore propose to kill it.

----------
components: Tests
messages: 123979
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: kill runtests.sh
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10706>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:04:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 22:04:04 +0000
Subject: [issue10707] compileall is broken
In-Reply-To: <1292364244.37.0.894892312979.issue10707@psf.upfronthosting.co.za>
Message-ID: <1292364244.37.0.894892312979.issue10707@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ ./python -m compileall
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/antoine/py3k/__svn__/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/antoine/py3k/__svn__/Lib/compileall.py", line 223, in <module>
    exit_status = int(not main())
  File "/home/antoine/py3k/__svn__/Lib/compileall.py", line 205, in main
    if os.path.isdir(dest):
  File "/home/antoine/py3k/__svn__/Lib/genericpath.py", line 41, in isdir
    st = os.stat(s)
TypeError: Can't convert 'NoneType' object to str implicitly

----------
components: Library (Lib)
messages: 123980
nosy: benjamin.peterson, ncoghlan, pitrou
priority: high
severity: normal
status: open
title: compileall is broken
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10707>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:04:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 22:04:16 +0000
Subject: [issue10707] compileall is broken
In-Reply-To: <1292364244.37.0.894892312979.issue10707@psf.upfronthosting.co.za>
Message-ID: <1292364256.52.0.105062570415.issue10707@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10707>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:17:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Dec 2010 22:17:57 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292365077.93.0.369481403105.issue10704@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The 10.4u SDK is an optional install in the OS X 10.6 Xcode Developer Tools package.  There is an option in the Xcode installer to customize; just select the 10.4u package to install it.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:19:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Dec 2010 22:19:36 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292365176.12.0.851021162128.issue10453@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Works under Windows 7.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:26:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 22:26:22 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292365582.41.0.214836865176.issue10704@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

FWIW, I was able to install Regex 0.1.20101210 on OSX 10.6.4, 

Developer Information:

  Version:	3.2 (10M2003)
  Location:	/Developer
  Applications:
  Xcode:	3.2.1 (1613)
  Interface Builder:	3.2.1 (740)
  Instruments:	2.0.1 (1096)
  Dashcode:	3.0 (328)
  SDKs:
  Mac OS X:
  10.5:	(9J61)
  10.6:	(10M2003)

using either python 3.1.2 or current py3k branch from svn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:33:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 22:33:57 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292366037.72.0.202380132094.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

committed in r87248.

----------
resolution:  -> accepted
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:37:00 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Dec 2010 22:37:00 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292366220.04.0.465412908926.issue10704@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

When you use python 3.1 from a python.org OS X installer, it is built with the 10.4u SDK and a deployment target of 10.3 and up. Distutils ensures that any extension modules are built using the same values as the interpreter itself which is why the 10.4u SDK is needed.  This is true for all current 32-bit ("10.3+") python.org installers for OS X.  If you build it yourself, you have other options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:38:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Dec 2010 22:38:05 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1292366285.73.0.784654057545.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for going through.  Nice patch!

----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:40:48 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 14 Dec 2010 22:40:48 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292366448.8.0.410284924344.issue10667@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

rhettinger's fastcount.patch looks good to me.  a couple style nits but they're minor.

no space between if and (?  yuck.   short variable names like "it"?  yuck.

but the code looks good otherwise.  i'm all for it.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:42:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 22:42:17 +0000
Subject: [issue10704] Regex 0.1.20101210 Python 3.1 install problem Mac OS X
	10.6.5
In-Reply-To: <1292350137.35.0.689383347761.issue10704@psf.upfronthosting.co.za>
Message-ID: <1292366537.92.0.584611616489.issue10704@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> If you build it yourself, you have other options.

Yes, my python3.1 is from MacPorts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10704>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:42:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 22:42:42 +0000
Subject: [issue10707] compileall is broken
In-Reply-To: <1292364244.37.0.894892312979.issue10707@psf.upfronthosting.co.za>
Message-ID: <1292366562.12.0.633176631213.issue10707@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Add -h/--help option to compileall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10707>
_______________________________________

From report at bugs.python.org  Tue Dec 14 23:45:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 22:45:14 +0000
Subject: [issue10706] kill runtests.sh
In-Reply-To: <1292363871.99.0.211094833748.issue10706@psf.upfronthosting.co.za>
Message-ID: <1292366714.76.0.852999914278.issue10706@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

+1

As far as I could tell it is left over from the pre-unittest days and not completely updated.  A few people may miss it, but they'll learn :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10706>
_______________________________________

From report at bugs.python.org  Wed Dec 15 00:03:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 23:03:45 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1292367825.78.0.0609813036882.issue10541@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that fixes write_results() and makes test_trace tests restore the tracefunc after they run.  This fixes generation off the coverage files, but many tests still fail when traced.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file20044/issue10541.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Wed Dec 15 00:33:35 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 23:33:35 +0000
Subject: [issue10705] HTTPConnection.set_debuglevel has no information about
	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292369615.14.0.910161418262.issue10705@psf.upfronthosting.co.za>


J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com> added the comment:

Hi David,
Currently the 3.1 documentation reads:
"""HTTPConnection.set_debuglevel(level)?
    Set the debugging level (the amount of debugging output printed). The default debug level is 0, meaning no debugging output is printed."""
How about:
"""HTTPConnection.set_debuglevel(level)?
    Set the debug level.  The debug level is the amount of debugging output printed. 
The default debug level is 0, meaning no debugging output is printed.
Currently, any debug level value greater than 0 prints the same amount of debugging output.
debugging output is printed to stdout."""

Information is from the file C:\Python\ActivePython3.1.2.3\Lib\http\client.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10705>
_______________________________________

From report at bugs.python.org  Wed Dec 15 00:35:56 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 23:35:56 +0000
Subject: [issue10705] HTTPConnection.set_debuglevel has no information about
	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292369756.84.0.067720304127.issue10705@psf.upfronthosting.co.za>


J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com> added the comment:

> Care to propose a patch?
oops.  I just found http://www.python.org/dev/patches/
I'll get around to creating a PEP sometime soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10705>
_______________________________________

From report at bugs.python.org  Wed Dec 15 00:47:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Dec 2010 23:47:57 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1292370477.75.0.333161707077.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Haypo describes his complicated patch as "useful on Windows", 
> but not critical

Usecase on Windows: your japanese friend gives you an USB key (eg. created on Windows with code page 932) with his Python project, you cannot run it on your english speaking Windows (eg. code page 1252), because it loads Python modules with japanese characters in their paths.

It works if all paths are encodable to your ANSI code page. It doesn't work if a least one character of one path is not encodable to your ANSI code page.

I don't know if this usecase is common or not.

Note: the FAT file system of the USB key stores filenames as UTF-16 (and not in the user code page).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Dec 15 00:48:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Dec 2010 23:48:09 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1292370489.88.0.835466180962.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Haypo describes his complicated patch as "useful on Windows", 
> but not critical

Usecase on Windows: your japanese friend gives you an USB key (eg. created on Windows with code page 932) with his Python project, you cannot run it on your english speaking Windows (eg. code page 1252), because it loads Python modules with japanese characters in their paths.

It works if all paths are encodable to your ANSI code page. It doesn't work if a least one character of one path is not encodable to your ANSI code page.

I don't know if this usecase is common or not.

Note: the FAT file system of the USB key stores filenames as UTF-16 (and not in the user code page).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Dec 15 00:50:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 23:50:48 +0000
Subject: [issue10703] Regex 0.1.20101210
In-Reply-To: <1292348517.73.0.298960721159.issue10703@psf.upfronthosting.co.za>
Message-ID: <1292370648.41.0.167092393341.issue10703@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: mark.dickinson -> 
nosy:  -mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10703>
_______________________________________

From report at bugs.python.org  Wed Dec 15 01:55:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 00:55:07 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1292374507.17.0.810977401268.issue2226@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Minor point of clarity: you mean __rand__ not __radd__, right?  Set objects do not support addition at all.

Adding the __rand__ methods to collections.Set in and of itself is straightforward:

    def __rsub__(self, other):
        return self._from_iterable(other) - self
    __ror__ = __or__
    __rand__ = __and__
    __rxor__ = __xor__

I'm not sure I understand the can of worms.  While replacing concrete tests with abstract tests may be worthwhile goal in its own right, why is it necessary to solve the particular shortcoming of missing __r* methods?

Probably I'm missing something.  With just the minimal change above, what kinds of things do you expect to fail?

(assuming Issue8743 is also fixed)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:18:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 01:18:12 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292375892.19.0.527096427489.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:18:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 01:18:51 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292375931.4.0.229911196796.issue2771@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

testing autonosy for release managers with release blockers

----------
nosy: +barry, benjamin.peterson, ezio.melotti, georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:20:34 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 01:20:34 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292376034.73.0.430427300225.issue2771@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Works fine. Now release managers will be added automatically to the nosy list when the priority of an issue is set to 'release blocker'.
See http://psf.upfronthosting.co.za/roundup/meta/issue363

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:36:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 01:36:45 +0000
Subject: [issue4236] Crash when importing builtin module during interpreter
	shutdown
In-Reply-To: <1225328266.56.0.143062114726.issue4236@psf.upfronthosting.co.za>
Message-ID: <1292377005.54.0.70844167169.issue4236@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r87251, 3.1 in r87252, and 2.7 in r87255.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:41:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 01:41:31 +0000
Subject: [issue10705] HTTPConnection.set_debuglevel has no information about
	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292377291.1.0.0582618954779.issue10705@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think a PEP is a bit of overkill for a small doc update :)  A patch would be fine...but I can also just make the change.  I'll probably tweak your wording a bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10705>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:44:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 01:44:35 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292377475.39.0.162114023012.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -ajaksu2, barry, benjamin.peterson, georg.brandl, loewis
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:44:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 01:44:46 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292377486.07.0.921928857206.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: normal -> release blocker
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:53:17 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 01:53:17 +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: <1292377997.22.0.390032053991.issue8743@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Would it be sufficient to:

1) Restrict collections.Set()'s operators to accept collection.Set but not arbitrary iterables, and
2) Fix Issue2226 and let set() | MySimpleSet() work via collections.Set.__ror__

Attached is a patch that implements this approach, nominally fixing both this and Issue2226.

This solutions seems much too simple in light of how long I've been thinking about these bugs.  I suspect there are code hobgoblins waiting to ambush me. ;)

----------
Added file: http://bugs.python.org/file20045/set-with-Set.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:53:42 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Dec 2010 01:53:42 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1292378022.84.0.0889108820136.issue2212@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:55:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Dec 2010 01:55:46 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1292378146.73.0.684495446906.issue2212@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Presumably not an issue for 3.1/3.2.

(Terry - I assume Sean means the fix is in the bug report comment when he says 'inline'.) A patch and a test would still be nice.

----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Wed Dec 15 02:56:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 15 Dec 2010 01:56:52 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1292378212.14.0.3313232297.issue2212@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:20:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 02:20:38 +0000
Subject: [issue10705] HTTPConnection.set_debuglevel has no information about
	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292379638.34.0.0719833056243.issue10705@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've committed a fix in r87256.  I looked at the code some more and tried to be a precise as possible without getting too wordy.  (The fix will get backported by and by.)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10705>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:27:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:27:21 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292380041.18.0.623699162178.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: release blocker -> deferred blocker
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:27:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:27:30 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292380050.72.0.631827848611.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl
priority: deferred blocker -> release blocker
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:27:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:27:54 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292380074.15.0.483508074278.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -georg.brandl
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:28:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:28:02 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292380082.01.0.290190688172.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: deferred blocker -> release blocker
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:34:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Dec 2010 02:34:53 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1292380493.02.0.341567742643.issue2212@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is not a security issue, so removal of 2.6 was right the first time.
Changing the one line would be easy, but I know nothing about what is correct or if there is even a standard for cookies.

----------
stage:  -> unit test needed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:51:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:51:49 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381509.26.0.011845141746.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:51:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:51:54 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381514.43.0.158601895288.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:51:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:51:59 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381519.48.0.562698357067.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:52:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:52:11 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381531.21.0.323084783217.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl
priority:  -> release blocker
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:52:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:52:20 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381540.14.0.76669385554.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority: release blocker -> 
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:53:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:53:35 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381615.64.0.965370532793.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -georg.brandl
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:57:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:57:24 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381844.32.0.272420066071.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:57:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:57:35 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381855.42.0.991133494103.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -georg.brandl
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:57:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:57:42 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381862.66.0.162102061522.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl
priority:  -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 03:57:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 02:57:55 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1292381875.23.0.235255959927.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -georg.brandl
priority: release blocker -> 
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Wed Dec 15 04:22:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 03:22:51 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292383371.7.0.0868416997834.issue8040@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you want to work on this you should also consider that the URLs used on docs.python.org don't necessary match the directory structure present when building the doc locally. For example here it would be:
.../py3k/library/fractions.html
.../release31-maint/library/fractions.html
.../release27-maint/library/fractions.html
.../release26-maint/library/fractions.html

This could be addressed with a config file that is not kept under version control (and possibly with default values used when this file is not present).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Wed Dec 15 04:32:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 03:32:08 +0000
Subject: [issue10618] regression in subprocess.call() command quoting
In-Reply-To: <1291407707.04.0.982354776271.issue10618@psf.upfronthosting.co.za>
Message-ID: <1292383928.09.0.126763936907.issue10618@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Tim: we just do our best to guess, and try to err on the conservative side.  But things will always happen.  Given benjamin's reply I'm closing the issue.  Mercurial would have to add conditional code now anyway no matter what we do.

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10618>
_______________________________________

From report at bugs.python.org  Wed Dec 15 05:04:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 15 Dec 2010 04:04:28 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1289654256.3572.1.camel@localhost.localdomain>
Message-ID: <20101215040412.GA1716@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, Nov 13, 2010 at 01:17:47PM +0000, Antoine Pitrou wrote:
> There are still sporadic failures such as:

I have made a small change for this in r87260.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Wed Dec 15 06:17:12 2010
From: report at bugs.python.org (Duncan Findlay)
Date: Wed, 15 Dec 2010 05:17:12 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1292390232.92.0.0813405682108.issue1975@psf.upfronthosting.co.za>


Duncan Findlay <duncan at duncf.ca> added the comment:

This is definitely still an issue.

With the "pthread_sig" patch attached to this bug, both on FreeBSD and on linux, any processes spawned from a thread seem to have their signals blocked, so they can not be killed.

Without it, on FreeBSD, the behavior described by bamby is still a problem.

I've attached a test case that adapts bamby's example code into a test, and shows the "unkillable subprocess" problem I described above.

On FreeBSD without the patch, test_signal fails, and with the patch test_thr fails.

On Linux and OS X, without the patch, all tests pass. With the patch, test_thr fails.

I hope somebody can come up with a better fix.

----------
Added file: http://bugs.python.org/file20046/thread_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Wed Dec 15 06:33:06 2010
From: report at bugs.python.org (Duncan Findlay)
Date: Wed, 15 Dec 2010 05:33:06 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1292391186.44.0.659671811451.issue1975@psf.upfronthosting.co.za>


Changes by Duncan Findlay <duncan at duncf.ca>:


Removed file: http://bugs.python.org/file20046/thread_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Wed Dec 15 06:33:32 2010
From: report at bugs.python.org (Duncan Findlay)
Date: Wed, 15 Dec 2010 05:33:32 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1292391212.12.0.598410014919.issue1975@psf.upfronthosting.co.za>


Changes by Duncan Findlay <duncan at duncf.ca>:


Added file: http://bugs.python.org/file20047/thread_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Wed Dec 15 09:46:59 2010
From: report at bugs.python.org (Finkregh)
Date: Wed, 15 Dec 2010 08:46:59 +0000
Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first
	time
Message-ID: <1292402819.12.0.525922872942.issue1633941@psf.upfronthosting.co.za>


Changes by Finkregh <finkregh at mafia-server.net>:


----------
nosy: +Finkregh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633941>
_______________________________________

From report at bugs.python.org  Wed Dec 15 10:09:18 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Wed, 15 Dec 2010 09:09:18 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1292404158.66.0.000344950202048.issue5625@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

Could you please add this change to test_urllib2.py as well?

It has the following line:
            localaddr = socket.gethostbyname(socket.gethostname())

But urllib2.py has the change related to this bug.
That makes test_urllib2 failing when gethostbyname reports different IP than gethostbyname_ex:

(Pdb) socket.gethostbyname_ex(socket.gethostname())[2]
['172.31.92.26']
(Pdb) socket.gethostbyname(socket.gethostname())
'172.31.72.206'

----------
nosy: +csernazs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Wed Dec 15 10:24:03 2010
From: report at bugs.python.org (Michael Buckley)
Date: Wed, 15 Dec 2010 09:24:03 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292405043.58.0.0460845624588.issue8040@psf.upfronthosting.co.za>


Michael Buckley <newsletters at codefisher.org> added the comment:

You might want to check out what Django does, as they have the working well.  http://docs.djangoproject.com/en/dev/

----------
nosy: +codefisher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Wed Dec 15 10:46:18 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 15 Dec 2010 09:46:18 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292406378.83.0.73114508743.issue6791@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a unit test which tests the issue.
Unfortunately, since it uses the resource module to limit memory to a workable size, it will only work on Unix.

The given patch appears to fix the issue well.

I think this should be taken as a security issue (even if a rather odd one) since a malicious http server could be set up in place of the normal one and crash any http python clients that connect to it.

Eg:
Run: dd if=/dev/zero bs=10M count=1000 | nc -l 8888
And then:

import httplib
h = httplib.HTTPConnection('localhost', 8888)
h.connect()
h.request('GET', '/')
r = h.getresponse()

This should cause python to use up all the memory available.

----------
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20048/i6791_unittest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Wed Dec 15 10:47:49 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 15 Dec 2010 09:47:49 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292406469.99.0.878546638453.issue6791@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

A py3k patch against revision 87228.

----------
Added file: http://bugs.python.org/file20049/i6791_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Wed Dec 15 11:20:34 2010
From: report at bugs.python.org (Yevgeniy)
Date: Wed, 15 Dec 2010 10:20:34 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292408434.45.0.518621905416.issue10692@psf.upfronthosting.co.za>


Yevgeniy <shchemelevev at gmail.com> added the comment:

>Have you confirmed that the same server is listening on port 993 as is listening on port 143? 
I found that is mistake in courier-imap(-ssl) configuration.
I have some troubles with it configuring(may by incorrect certificates).
When i make right configuration i will test again python code and writ? here results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Wed Dec 15 11:30:16 2010
From: report at bugs.python.org (Steve Moran)
Date: Wed, 15 Dec 2010 10:30:16 +0000
Subject: [issue10703] Regex 0.1.20101210
In-Reply-To: <1292356048.22.0.813686928575.issue10703@psf.upfronthosting.co.za>
Message-ID: <alpine.LRH.2.01.1012150228490.22853@homer02.u.washington.edu>


Steve Moran <stiv at uw.edu> added the comment:

(Forehead slap.)

On Tue, 14 Dec 2010, Matthew Barnett wrote:

>
> Matthew Barnett <python at mrabarnett.plus.com> added the comment:
>
> The regex module is intended to replace the re module, so its default behaviour is the same: in Python 2, regexes default to matching ASCII, and in Python 3, they default to matching Unicode.
>
> If you want to use a regex on a Unicode string in Python 2 then you need to set the Unicode flag, either by providing the UNICODE flag or by putting "(?u)" in the regex itself.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10703>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10703>
_______________________________________

From report at bugs.python.org  Wed Dec 15 11:54:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 15 Dec 2010 10:54:28 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1292404158.66.0.000344950202048.issue5625@psf.upfronthosting.co.za>
Message-ID: <20101215105416.GB13047@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Zsolt,

The change in the urllib2 was at a place where tuple of all local ips
were required.
In test_urllib2, which testcase failed?
Also, can you make this change and see if this helps in your case.

-             localaddr = socket.gethostbyname(socket.gethostname())
+             localaddr = socket.gethostbyname('localhost')

If this is sufficient, this change can be made in the trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Wed Dec 15 12:55:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 11:55:12 +0000
Subject: [issue1975] signals not always delivered to main thread,
	since other threads have the signal unmasked
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1292414112.11.0.376068211038.issue1975@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/issue1975>
_______________________________________

From report at bugs.python.org  Wed Dec 15 13:14:44 2010
From: report at bugs.python.org (Florian Berger)
Date: Wed, 15 Dec 2010 12:14:44 +0000
Subject: [issue7639] bdist_msi fails on files with long names
In-Reply-To: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>
Message-ID: <1292415284.82.0.97019554973.issue7639@psf.upfronthosting.co.za>


Florian Berger <fberger at florian-berger.de> added the comment:

I can confirm that this issue persists in Python 3.1.2 on win32. The patch by cgohlke from 2010-10-22 fixes the problem here as well.

----------
nosy: +fberger
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7639>
_______________________________________

From report at bugs.python.org  Wed Dec 15 14:34:28 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Wed, 15 Dec 2010 13:34:28 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1292420068.68.0.346834467459.issue5625@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

The test which failed was HandlerTests.test_file, and I'm using python 2.7.1.

socket.gethostbyname('localhost') returns "127.0.0.1" which is ok, but in the unittest it's already tested (line 671).

The problem is that my /etc/hosts file contains a different IP than the DNS (I cannot change this behaviour as I'm not the administrator of the host) and that's the difference between gethostbyname and gethostbyname_ex.

The unittest creates an url which is not local (from urllib2 point of view). I'm attaching a patch which has fixed my problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file20050/test_urllib2.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Wed Dec 15 14:40:27 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 15 Dec 2010 13:40:27 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1292420068.68.0.346834467459.issue5625@psf.upfronthosting.co.za>
Message-ID: <AANLkTimGCne3uYVQc2b+Pjap3okCYnboR8shpcMDc3a7@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

+            localaddr = socket.gethostbyname_ex(socket.gethostname())[2][0]

May not be a generic solution, because in another system the other ip
could be first in the list.  Because the failure was in the test_file,
which was basically exercising file://'localhost' in the url, I
suggested that you replace with 'localhost'. I think, the solution is
okay, even thought localhost has been exercised in another test.

----------
Added file: http://bugs.python.org/file20051/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________
-------------- next part --------------
<span class="Apple-style-span" style="font-family: &#39;Times New Roman&#39;; font-size: medium; "><pre style="word-wrap: break-word; white-space: pre-wrap; ">+            localaddr = socket.gethostbyname_ex(socket.gethostname())[2][0]</pre>

<pre style="word-wrap: break-word; white-space: pre-wrap; ">May not be a generic solution, because in another system the other ip could be first in the list.  Because the failure was in the test_file, which was basically exercising file://&#39;localhost&#39; in the url, I suggested that you replace with &#39;localhost&#39;. I think, the solution is okay, even thought localhost has been exercised in another test.</pre>

</span>

From report at bugs.python.org  Wed Dec 15 14:53:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 13:53:47 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1292421227.58.0.0327999503203.issue9319@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

help no longer segfaults, but the find_module call still does; updating title.  The patch does cure the segfault, but as Stefan says it isn't the best fix since having '<file>' in the error message instead of the real file name isn't very useful.

----------
nosy: +r.david.murray
title: segfault when searching modules with help() -> imp.find_module('test/badsyntax_pep3120') causes segfault

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Wed Dec 15 15:01:53 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Wed, 15 Dec 2010 14:01:53 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1292421713.97.0.320098997563.issue5625@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

The order of the IP addresses doesn't matter as urllib2 is flexible enough to handle all local IP addresses as local (that was the original bug - it handled only one IP returned by gethostbyname which returned a random IP if there were more than one).

So picking up the first IP is ok I think as the order of the IP addresses doesn't matter - urllib2 will handle all of them as local.
See urllib2.FileHandler.get_names().

The problem is that gethostbyname doesn't guarantee that it returns one IP address from the set returned by gethostbyname_ex as gethostbyname looks up the name in /etc/hosts file first (or as configured in NSS).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:02:54 2010
From: report at bugs.python.org (Charles Duffy)
Date: Wed, 15 Dec 2010 15:02:54 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1292425374.45.0.585751028891.issue2212@psf.upfronthosting.co.za>


Charles Duffy <charles at dyfis.net> added the comment:

Only the Comment field of a cookie is required by RFC2965 to support Unicode -- and several major browsers either mangle or discard cookies containing even high-ASCII values.

Consequently, while some kind of unicode support is appropriate to implement, any program depending on end-to-end support for unicode-encoded cookies is in practice behaving perilously.

----------
nosy: +charles at dyfis.net

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:07:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:07:46 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292425666.07.0.834734424059.issue6791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

First, I don't think the resource module needs to be used here. Second, I don't see why getcode() would return 200. If no valid response was received then some kind of error should certainly be raised, shouldn't it?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:33:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:33:37 +0000
Subject: [issue10706] kill runtests.sh
In-Reply-To: <1292363871.99.0.211094833748.issue10706@psf.upfronthosting.co.za>
Message-ID: <1292427217.28.0.374993441285.issue10706@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r87261.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10706>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:37:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:37:33 +0000
Subject: [issue10708] Misc/porting should be folded in to the development FAQ
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Title says it all.

----------
assignee: brett.cannon
components: Documentation
messages: 124023
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Misc/porting should be folded in to the development FAQ
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10708>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:49:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:49:22 +0000
Subject: [issue10656] "Out of tree" build fails on AIX 5.3
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1292428162.44.0.489537636504.issue10656@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10656>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:50:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:50:56 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

S?bastien, would you like to provide an updated version of that file? The current contents look hopelessly outdated.

----------
assignee: docs at python
components: Documentation
messages: 124024
nosy: docs at python, pitrou, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: Misc/AIX-NOTES needs updating
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Wed Dec 15 16:53:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:53:37 +0000
Subject: [issue10710] Is Misc/setuid-prog.c still needed?
In-Reply-To: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>
Message-ID: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I guess it was created for ease of hosting CGI scripts written in Python, but is it still useful (or even functional) nowadays? Last updated goes back to 1998.

----------
components: Demos and Tools
messages: 124025
nosy: brett.cannon, gvanrossum, jhylton, pitrou, r.david.murray
priority: low
severity: normal
status: open
title: Is Misc/setuid-prog.c still needed?
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10710>
_______________________________________

From report at bugs.python.org  Wed Dec 15 17:25:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 16:25:38 +0000
Subject: [issue10710] Is Misc/setuid-prog.c still needed?
In-Reply-To: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>
Message-ID: <1292430338.03.0.0529394125844.issue10710@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I started out writing that there must be better stuff available now for doing this, but a search on 'setuid wrapper' on google reveals mostly people asking about or talking about rolling their own special purpose scripts.

That said, there is at least one better alternative in the CGI context, which is Apache suexec support.

Overall, I don't think we want to be responsible for supporting this, since it really about OS level security and not a core expertise of the Python community.  I'd vote for dropping it.  After all, it will still be available in the source tarballs for older versions of Python, and it was never meant to be used directly anyway.

Personally, in this day and age I would never have thought to look in the Misc directory of the Python tarball for a setuid wrapper script.  I'd have started with google, and this script doesn't show up on first few pages, at least :)  So I don't think there's much value added in shipping this anymore, either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10710>
_______________________________________

From report at bugs.python.org  Wed Dec 15 17:31:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 15 Dec 2010 16:31:56 +0000
Subject: [issue10667] collections.Counter object in C
In-Reply-To: <1291935540.06.0.127378209926.issue10667@psf.upfronthosting.co.za>
Message-ID: <1292430716.18.0.316977611861.issue10667@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed "if(" spacing and applied in r87265.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10667>
_______________________________________

From report at bugs.python.org  Wed Dec 15 17:38:39 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 15 Dec 2010 16:38:39 +0000
Subject: [issue10509] PyTokenizer_FindEncoding can lead to a segfault if bad
	characters are found
In-Reply-To: <1290451032.87.0.502665724256.issue10509@psf.upfronthosting.co.za>
Message-ID: <1292431119.59.0.0660660033897.issue10509@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Yes, it is (at the latest since msg124018).

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10509>
_______________________________________

From report at bugs.python.org  Wed Dec 15 17:55:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 16:55:36 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292432136.58.0.433060833459.issue6791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, looking at the code, readline() without any parameter is used all over http.client, so fixing only this one use case doesn't really make sense.

----------
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:01:00 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 15 Dec 2010 17:01:00 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292432460.44.0.304896962978.issue6791@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

That's true. Near the bottom of the code, it says:

 # The status-line parsing code calls readline(), which normally
 # get the HTTP status line.  For a 0.9 response, however, this is
 # actually the first line of the body!

Limiting the length of the status line would break 0.9 responses so maybe this issue should be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:02:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 17:02:39 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1292432460.44.0.304896962978.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292432554.3665.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's true. Near the bottom of the code, it says:
> 
>  # The status-line parsing code calls readline(), which normally
>  # get the HTTP status line.  For a 0.9 response, however, this is
>  # actually the first line of the body!
> 
> Limiting the length of the status line would break 0.9 responses so maybe this issue should be closed?

Well, the HTTP 1.0 RFC was filed in 1996 and HTTP 1.1 is most commonly
used today. I don't think we need to support 0.9 anymore. I'll open a
separate issue for ripping off 0.9 support, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:04:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 17:04:58 +0000
Subject: [issue10711] Rip off HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Both http.client and http.server claim to support HTTP 0.9. The HTTP 1.0 RFC was filed in 1996, and 1.1 is most commonly used nowadays. We should probably rip off 0.9 support.

----------
components: Library (Lib)
messages: 124032
nosy: jhylton, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Rip off HTTP 0.9 support
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:14:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 17:14:56 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292433296.97.0.851109538766.issue10711@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: Rip off HTTP 0.9 support -> Rip out HTTP 0.9 support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:27:34 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 15 Dec 2010 17:27:34 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1292434054.76.0.141425707587.issue9319@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Pydoc skips the badsysntax_pep3120 file for now.  When this gets fixed that workaround should be removed.  The work around is commented and refers to this issue #.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:52:28 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 15 Dec 2010 17:52:28 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1292435548.04.0.353951264948.issue9319@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Wed Dec 15 18:54:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 17:54:25 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292435665.73.0.75763975933.issue10711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20052/removehttp09.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:01:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 18:01:26 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292436086.45.0.38757414729.issue10711@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:03:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 18:03:14 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292436194.73.0.281418679507.issue10711@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file20052/removehttp09.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:04:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 18:04:18 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292436258.93.0.292514512016.issue10711@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file20053/removehttp09.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:24:44 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Wed, 15 Dec 2010 18:24:44 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1292437484.11.0.938441294488.issue874900@psf.upfronthosting.co.za>


Changes by Bobby Impollonia <bobbyi at gmail.com>:


----------
nosy: +bobbyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:25:41 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Wed, 15 Dec 2010 18:25:41 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1292437541.84.0.205370227003.issue6721@psf.upfronthosting.co.za>


Changes by Bobby Impollonia <bobbyi at gmail.com>:


----------
nosy: +bobbyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:29:59 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 18:29:59 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

Attached is a patch to add documentation for Py_ReprEnter and Py_ReprLeave.  Assigning to docs at python for review.

----------
assignee: stutzbach -> docs at python
keywords: +needs review, patch
nosy: +docs at python
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20054/repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:37:49 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:37:49 +0000
Subject: [issue10693] error in documentation of
	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292438269.52.0.00613188202336.issue10693@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a fix for Doc/distutils/apiref.rst and Lib/distutils/archive_util.py in Python 3.2

If it's OK I will backport to other versions as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file20055/issue10693.py32.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10693>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:39:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:39:25 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1292438365.07.0.825133986274.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Updated patch with "versionadded" tag for the new methods

----------
Added file: http://bugs.python.org/file20056/issue10516.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:40:55 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:40:55 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292438455.46.0.106409411242.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Guys, this issue is pending for a long time. Anything else needed before a commit is done?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:43:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:43:47 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292438627.28.0.963448574585.issue9264@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:47:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 18:47:50 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292438870.85.0.730929568709.issue10711@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Would it be worth keeping (but modifying) test_http_0_9 to verify that the server complains in the expected way?

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:52:48 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 15 Dec 2010 18:52:48 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292439168.97.0.479860577495.issue10711@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Ripping HTTP "0.9" support _out_ flys directly in the face of "be lenient in what you accept and strict in what you produce."

I do not mind removing support from http.server.  But http.client needs to be able to communicate with any random server created since the dawn of time.  Often on 8 bit microcontrollers that haven't been updated since 1994.

How does keeping 0.9 client support in hurt us?

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 19:59:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 18:59:46 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292439586.28.0.249081977107.issue10711@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

At minimum, I think we should apply this part of Antoine's patch:

-    # Most web servers default to HTTP 0.9, i.e. don't send a status line.
-    default_request_version = "HTTP/0.9"
+    default_request_version = "HTTP/1.0"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:00:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 19:00:06 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292439606.51.0.754235215574.issue10711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But http.client needs to be able to communicate with any random server
> created since the dawn of time.

Well, that sounds a bit unreasonable...

> Often on 8 bit microcontrollers that haven't been updated since 1994.

Anyone with such needs should write specialized software, shouldn't they?

> How does keeping 0.9 client support in hurt us?

In any such situation, there's typically a long-term cost in additional maintenance when patching and improving the code.
More specifically, this issue came when discussing #6791. Protecting http.client against unbounded reads will be hairy if we have to support HTTP 0.9-style "simple responses".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:01:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 19:01:01 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292439661.63.0.702033258124.issue10711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Would it be worth keeping (but modifying) test_http_0_9 to verify that
> the server complains in the expected way?

Actually, I don't think the server will complain, since the request is legit. It will send back a full response with status line and headers, though, so the test has to be adapted indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:04:07 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 15 Dec 2010 19:04:07 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292439847.73.0.744828374457.issue10711@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/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:08:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 19:08:33 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292440113.17.0.325928633624.issue10573@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: michael.foord -> ezio.melotti
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:13:40 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Dec 2010 19:13:40 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292440420.06.0.421817357927.issue9264@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since ?ric grabbed Assigned To:, I was expecting him to ;=). But since he is doing enough other stuff, I will unless there are conflicts in the .rst I do not know how to fix.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:15:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 19:15:12 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292440512.88.0.675967712832.issue10711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch with adapted tests.

----------
Added file: http://bugs.python.org/file20061/removehttp09-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:16:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 19:16:08 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292440568.31.0.849453871969.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My current schedule is a bit crazy and I?ve had no time for Python bugs.

I changed ?programming? to ?programmatic?, slightly tweaked the phrasing for the --ignore-* options to make them hopefully more understandable and similar, and committed in r87271.

I?m currently rewrapping long lines and migrating the class/method constructs to be nested.  I will then backport the parts of both commits that apply to 3.1 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:27:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Dec 2010 19:27:52 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292441272.67.0.949817277595.issue9264@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

?ric beat me. Better that he finish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:31:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Dec 2010 19:31:05 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1292441465.66.0.54763316184.issue10541@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +eli.bendersky, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:32:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 19:32:20 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292441540.64.0.917578138696.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Minor whitespace and markup edits make r87273.  Please review and tell me if it?s okay for backport or if there are further improvements to be done first.  I promise I won?t beat anyone ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:36:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 19:36:12 +0000
Subject: [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292441772.69.0.761637050459.issue10702@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I was persuaded there was already a bug open with a patch adding bytes and bytearray in the sequence methods table, but I can?t find it.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10702>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:36:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 19:36:37 +0000
Subject: [issue10712] 2to3 fixer for deprecated unittest method names
In-Reply-To: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>
Message-ID: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch against 2.7 adds a new fixer to 2to3 that replaces deprecated unittest method names with the correct ones.
There are a few issues:
1) only the "safe" renamings are included; the assert[SameElements|ItemsEqual|CountEqual] and the  assert*Regexp*->assert*Regex* changes are missing;
2) unless 2to3 provides a way to specify a target version (e.g. 3.2 rather than just 3.x), the missing renamings can't be included;
3) the patch is against 2.7 but I'm not sure in what versions could/should be included, or if the fixer should (also|only) go on PyPI;
4) this fixer is useful from 3.1 to 3.2 too, is there a way to use it with 3.x versions only?
5) doc is still missing;

----------
files: issue10712.diff
keywords: needs review, patch
messages: 124054
nosy: benjamin.peterson, ezio.melotti, georg.brandl, michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 fixer for deprecated unittest method names
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20062/issue10712.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10712>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:40:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Dec 2010 19:40:58 +0000
Subject: [issue3446] center,
	ljust and rjust are inconsistent with unicode parameters
In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za>
Message-ID: <1292442058.13.0.529762407247.issue3446@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3446>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:46:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 19:46:00 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1292442360.45.0.796512591455.issue2576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This was apparently fixed in r69209.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:48:37 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 19:48:37 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292442517.78.0.197657421158.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric,

The nested methods are nice, though a bit unusual IMHO. Is this the recommended new way to markup methods of objects? [Because AFAIK it's not used much in other docs]

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:53:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 19:53:35 +0000
Subject: [issue6785] IncompleteRead / BadStatus when parsing
	http://peakoil.mobi
In-Reply-To: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
Message-ID: <1292442815.84.0.445227051912.issue6785@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That server simply doesn't respect the HTTP RFC. It fails to send a last "0" line to indicate that the chunked transfer has completed.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6785>
_______________________________________

From report at bugs.python.org  Wed Dec 15 20:55:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 19:55:55 +0000
Subject: [issue7013] Httplib read routine is not tolerant to not well-formed
	chunked http responses.
In-Reply-To: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>
Message-ID: <1292442955.55.0.0619482841673.issue7013@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7013>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:00:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 20:00:10 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1292443210.66.0.258791054477.issue1628205@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:05:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Dec 2010 20:05:02 +0000
Subject: [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292443502.29.0.95173238155.issue10702@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I was persuaded there was already a bug open with a patch adding
> bytes and bytearray in the sequence methods table, but I can?t find it.

I can't find it either, but this issue is different.  I propose renaming "String Methods" to "String, bytes and bytearray methods" and 


str.capitalize()
bytes.capitalize()
bytearray.capitalize()

Return a copy of the string with its first character capitalized and the rest lowercased.  [Discuss Unicode vs bytes details.]

BTW, the "For 8-bit strings, this method is locale-dependent." part is probably out of date because bytes.capitalize() seems to pass non-ASCII bytes through:

>>> bytes([ord('?')]).capitalize()[0] == ord('?')
True

and for unicode strings the operation is *not* locale dependent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10702>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:23:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Dec 2010 20:23:45 +0000
Subject: [issue10534] difflib.SequenceMatcher: expose junk sets,
	deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1292444625.73.0.698821429978.issue10534@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Added tweak to .__chain_b to avoid creating list of b2j.keys and .items be deleting from b2j in separate loop after creating sets. Test with timeit suggests time about same with 1% deletion. r87276

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10534>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:36:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 20:36:43 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1292445403.07.0.310515270345.issue9990@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:38:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 20:38:33 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1292445513.58.0.44327445926.issue8844@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:38:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 20:38:39 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1292445520.0.0.70156371536.issue8844@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies:  -Make gettimeofday available in time module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:40:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 20:40:12 +0000
Subject: [issue10538] PyArg_ParseTuple("s*") does not always incref object
In-Reply-To: <1290758853.31.0.608837110631.issue10538@psf.upfronthosting.co.za>
Message-ID: <1292445612.17.0.782696417185.issue10538@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10538>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:40:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 20:40:16 +0000
Subject: [issue10693] error in documentation of
	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292445616.56.0.811019819308.issue10693@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch extended to cover shutil, which has gained _make_{tar,zip}file in 2.7 and 3.2, and committed in all three branches in r87277 to r87279.

Will be fixed in distutils2 the next time I synchronize d2._backport.shutil.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10693>
_______________________________________

From report at bugs.python.org  Wed Dec 15 21:41:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 20:41:39 +0000
Subject: [issue5218] Check for tp_iter in ceval:ext_do_call before overriding
	exception message
In-Reply-To: <1234380763.79.0.974439208897.issue5218@psf.upfronthosting.co.za>
Message-ID: <1292445699.47.0.0701827085939.issue5218@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: pitrou -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5218>
_______________________________________

From report at bugs.python.org  Wed Dec 15 22:07:19 2010
From: report at bugs.python.org (Mark Florisson)
Date: Wed, 15 Dec 2010 21:07:19 +0000
Subject: [issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1292447239.38.0.855392263659.issue10566@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

Ok I attached a new patch that solves the things you mentioned. It can debug Python inferiors with versions 2.6+. Execution control commands (py-{run, cont, finish, step, next}) and py-exec need gdb 7.2+, py-break works with 7.1+.

It now also "supports exceptions", which means that if there is a pending exception when control is transferred to the debugger, the exception is printed (safely).
Also stepping and stepping over should be a lot faster as it now uses hardware watchpoints that watch the instruction pointer (f->f_lasti).

----------
Added file: http://bugs.python.org/file20070/libpython.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Wed Dec 15 22:07:52 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 15 Dec 2010 21:07:52 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292447272.92.0.15452078198.issue10711@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Given the 6961 issue I'm happy to change my position and say we nuke the 0.9 client support.

Anyone who _needs_ that can grab this old code or write trivial code for their poor server's needs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Wed Dec 15 22:17:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 21:17:31 +0000
Subject: [issue9558] build_ext fails on VS8.0
In-Reply-To: <1281450935.69.0.209009694295.issue9558@psf.upfronthosting.co.za>
Message-ID: <1292447851.84.0.32090178423.issue9558@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in [4f2da1ec00a2] (distutils2), r87280 (3.2), r87201 (3.1), r87282 (2.7).  Thanks to you both.

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9558>
_______________________________________

From report at bugs.python.org  Wed Dec 15 22:25:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 21:25:50 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292448350.68.0.129101216548.issue9286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have not read email RFCs, so I will defer to you.  One suggestion for the patch, though: Use example.org instead of rusty.com (see RFC 2606).

I tried the examples in Icedove (free Thunderbird), either it finds a matching contact or it refuses to send the message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Wed Dec 15 22:29:51 2010
From: report at bugs.python.org (Jonathan Halcrow)
Date: Wed, 15 Dec 2010 21:29:51 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292448591.44.0.070411500232.issue10254@psf.upfronthosting.co.za>


Jonathan Halcrow <jonathan.halcrow at gmail.com> added the comment:

I think I've come across a related problem.  I am experiencing a segfault when NFC-normalizing a certain string [1].
The crash occurs with 2.7.1 in OS X (built from source with homebrew).   

Here is the backtrace:
#0  0x0025a96e in _PyUnicode_Resize ()
#1  0x00601673 in nfc_nfkc ()
#2  0x00601bb7 in unicodedata_normalize ()
#3  0x0029834b in PyEval_EvalFrameEx ()
#4  0x00299f13 in PyEval_EvalCodeEx ()
#5  0x0029a0fe in PyEval_EvalCode ()
#6  0x002bd5f0 in PyRun_FileExFlags ()
#7  0x002be430 in PyRun_SimpleFileExFlags ()
#8  0x002d5bd6 in Py_Main ()
#9  0x00001f8f in _start ()
#10 0x00001ebd in start ()


[1] http://pastebin.com/cfNd2QEz

----------
nosy: +jhalcrow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Wed Dec 15 22:54:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 21:54:26 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292450066.99.0.515708276265.issue10254@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can reproduce the crash under 2.7, but not 2.6 or 3.x here. So it might be a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:18:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 22:18:31 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292451511.31.0.0377666435586.issue10254@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

After a bit of debugging, the crash is due to the "skipped" array being overflowed in nfc_nfkc() in unicodedata.c. "cskipped" goes up to 21 while the array only has 20 entries. This happens in all branches (but only crashes in 2.7 right now for probably unimportant reasons).

And the problem was indeed introduced by Victor's patch in issue1054943. Just before, "cskipped" would only go up to 1.

----------
priority: normal -> high
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:19:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 15 Dec 2010 22:19:43 +0000
Subject: [issue10712] 2to3 fixer for deprecated unittest method names
In-Reply-To: <1292441796.9.0.018359428873.issue10712@psf.upfronthosting.co.za>
Message-ID: <1292451583.91.0.180646591751.issue10712@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

2to3 patches should currently be made against and checked into the sandbox.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10712>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:21:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:21:19 +0000
Subject: [issue6007] Add disclaimer about MinGW compat in distutils docs
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1292451679.59.0.979278048521.issue6007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch applied after small editions in [a8e0f46fccbd] (distutils2), r87283 (3.2), r87285 (3.1), r87287 (2.7).

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: pending -> closed
title: distutils tricks you into thinking you can build extensions with mingw -> Add disclaimer about MinGW compat in distutils docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:24:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 22:24:35 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292451875.5.0.156276401735.issue9286@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see any reason to use example.com in tests that are not talking to the network and aren't documentation.

The interesting question about the other mailers is, if you *receive* an email with such an address (1) what does it show you and (2) what does it put into the To: field when you do a 'reply'?  How you arrange to receive such a broken email, I'm not sure :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:29:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:29:05 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292452145.64.0.730639832628.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The nesting allows logical grouping in source and output, saves a bit of typing, and has been added to a number of files by Benjamin Peterson.  I?d say it?s recommended :)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:32:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 22:32:21 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292452341.2.0.257969875945.issue9286@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On the other hand, putting a real domain name that belongs to somebody else into our code base even as a test string is probably impolite without asking, so I'll change it when I commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:35:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 22:35:11 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292452511.68.0.458565158076.issue8753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think this is a bit misleading. These functions are only needed if you are implementing a container. For the general case where you don't display another Python object in your repr() (or you only display objects which are themselves atomic, such as strings and integers), these functions are not necessary.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:39:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:39:47 +0000
Subject: [issue8851] pkgutil documentation needs more markup
In-Reply-To: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>
Message-ID: <1292452787.47.0.758378762417.issue8851@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Missing markup for one ``None`` added in r87289 and following revisions for maintenance branches.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8851>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:42:16 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 22:42:16 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292452936.53.0.674395409169.issue8753@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Good point.  My perspective is skewed by all of the time that I spend working on container types. :-)

How about if I change the first sentence to the following?

    Properly implementing :attr:`tp_repr` for container types requires
    special recursion handling.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:44:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:44:45 +0000
Subject: [issue7694] DeprecationWarning from build_ext needs stacklevel
In-Reply-To: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>
Message-ID: <1292453085.63.0.180277840015.issue7694@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg113018

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7694>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:51:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:51:32 +0000
Subject: [issue7694] DeprecationWarning from build_ext needs stacklevel
In-Reply-To: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>
Message-ID: <1292453492.93.0.864429271949.issue7694@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I checked again and found those files to be fixed in 3.2: (in Lib/distutils) command/register.py command/sdist.py dist.py extension.py.  Instances of self.warn or file.warn are false positives, they are logging calls.

The situation is different in distutils2: Deprecated code is ripped off, and remaining warnings should probably be made logging warnings.

----------
components: +Distutils -Distutils2
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7694>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:54:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 22:54:26 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292452936.53.0.674395409169.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292453662.3665.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How about if I change the first sentence to the following?
> 
>     Properly implementing :attr:`tp_repr` for container types requires
>     special recursion handling.

This looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:56:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:56:56 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292453816.49.0.301354143196.issue9286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, it?s either impolite or free advertisement.

Ideas to receive such a malformed email: Use a valid email in From but not in Reply-To; write it by hand and put it in your maildir.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:57:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 22:57:11 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292453831.72.0.840075352501.issue8753@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


Added file: http://bugs.python.org/file20071/repr-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:58:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:58:32 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292453912.27.0.165711684515.issue8753@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Possibly related: #9840

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Wed Dec 15 23:59:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 22:59:57 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1292453997.17.0.140154563367.issue8844@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r87292. Thank you for doing this!

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Thu Dec 16 00:05:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 23:05:07 +0000
Subject: [issue1274324] 'setup.py install' fails on linux from read-only
	storage
Message-ID: <1292454307.83.0.146299619606.issue1274324@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Guidelines for someone wanting to make a patch: http://wiki.python.org/moin/Distutils/FixingBugs

I?m adding the easy keyword to let a sprinter or bug-day newcomer find this and write a test.  The fix itself may be more difficult, since the error message looks like it comes from a program called by distutils.

----------
components: +Distutils2
stage:  -> needs patch
title: 'setup.py install' fail on linux from read-only storage -> 'setup.py install' fails on linux from read-only storage
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1274324>
_______________________________________

From report at bugs.python.org  Thu Dec 16 00:05:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 23:05:08 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292454308.46.0.194923764698.issue8753@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Thanks.  New patch attached with a cross-reference to reprlib.recursive_repr.

----------
Added file: http://bugs.python.org/file20072/repr-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Thu Dec 16 00:07:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 23:07:30 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292454450.1.0.382342930777.issue8753@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch LGTM, except for ?As examples? which I?ve never read before (but I?m not a native speaker).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Thu Dec 16 00:09:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 23:09:08 +0000
Subject: [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1292454548.77.0.229843053812.issue10191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For the record, I have started work on this, then stopped due to lack of time.  I?ll get back to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10191>
_______________________________________

From report at bugs.python.org  Thu Dec 16 00:12:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 23:12:01 +0000
Subject: =?utf-8?q?=5Bissue9322=5D_Don=E2=80=99t_fail_silently_if_ext=5Fmodules_us?=
	=?utf-8?q?e_absolute_paths?=
In-Reply-To: <1279721130.09.0.919872519995.issue9322@psf.upfronthosting.co.za>
Message-ID: <1292454721.0.0.401198838164.issue9322@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9322>
_______________________________________

From report at bugs.python.org  Thu Dec 16 00:48:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 23:48:05 +0000
Subject: [issue10510] distutils upload/register should use CRLF in HTTP
	requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1292456885.06.0.997924420611.issue10510@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Updated guidelines: http://wiki.python.org/moin/Distutils/FixingBugs

> is it currently impossible to test the current svn version of
> distutils in the current svn version of Python?
It is.  Branches that get bugfixes are 3.2, 3.1 and 2.7; each one has its interpreter code and its distutils lib and tests.  I?m not sure what prompted your question: was it something on the patches guideline page?

----------
components:  -Distutils
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Thu Dec 16 01:14:55 2010
From: report at bugs.python.org (Adrian Sampson)
Date: Thu, 16 Dec 2010 00:14:55 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292458495.19.0.15842682885.issue9234@psf.upfronthosting.co.za>


Adrian Sampson <asampson at cs.washington.edu> added the comment:

Great. I've added a simple example to the documentation for argparse. I also added a space to the comma separator in the alias list, but I'm worried that adding 'aliases:' will make the help less readable (especially if every command in a long list has aliases).

----------
Added file: http://bugs.python.org/file20073/argparse-aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Thu Dec 16 01:36:57 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 16 Dec 2010 00:36:57 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292459817.63.0.958495489798.issue9234@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Georg, be our hero here. I would be disappointed if this missed 3.2 and made us wait another 18 months (or 3 years for Linux distribution inclusion) for that feature.

This feature makes the first edition of argparse in py3k complete in terms of subcommands.

----------
nosy: +georg.brandl, lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Thu Dec 16 01:43:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 00:43:21 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292460201.17.0.607072428407.issue9234@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good and ready to me.

Regarding ?alias? in help text, note that Mercurial prints it (using one line for them) but Subversion puts aliases in parentheses just after the main command name, which works very for me (not a beginner).  Stephen, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Thu Dec 16 02:05:35 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Thu, 16 Dec 2010 01:05:35 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

The re module defines \b in a regexp to need \w one side and \W the other.  What about when the end of the string or line is involved?  perlre(1) says that's treated as a \W.  Python should precisely document that case too.

----------
assignee: docs at python
components: Documentation
messages: 124097
nosy: docs at python, ralph.corderoy
priority: normal
severity: normal
status: open
title: re module doesn't describe string boundaries for \b

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Thu Dec 16 02:06:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 16 Dec 2010 01:06:44 +0000
Subject: [issue10538] PyArg_ParseTuple("s*") does not always incref object
In-Reply-To: <1290758853.31.0.608837110631.issue10538@psf.upfronthosting.co.za>
Message-ID: <1292461604.0.0.53697087497.issue10538@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well, I can submit a patch if anyone is interested.
I came across this when writing asynchronous network code.  By hanging onto the Py_buffer, I should have access to the data during the network call.  But it only worked for "true" Py_buffer objects and not the others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10538>
_______________________________________

From report at bugs.python.org  Thu Dec 16 02:13:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 01:13:07 +0000
Subject: [issue9281] Race condition with mkdir/makedirs in distutils2
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1292461987.71.0.0022003583014.issue9281@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to backport the new makedirs function to d2/_backport/__init__.py?

----------
keywords: +easy -patch
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Thu Dec 16 02:21:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 01:21:13 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292462473.19.0.817282850744.issue10559@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

New wording:

 When known to the interpreter, the script name and additional arguments
 thereafter are passed to the script in the variable ``sys.argv``, which is a
-list of strings.  Its length is at least one; when no script and no arguments
+list of strings.  You have to execute ``import sys`` before you can use that
+list.  Its length is at least one; when no script and no arguments
 are given, ``sys.argv[0]`` is an empty string.  When the script name is given as
 ``'-'`` (meaning  standard input), ``sys.argv[0]`` is set to ``'-'``.  When
 :option:`-c` *command* is used, ``sys.argv[0]`` is set to ``'-c'``.  When

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Thu Dec 16 02:28:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 01:28:37 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1292462917.69.0.733007312539.issue10609@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IMO, wrapping db in a dict defeats the purpose of dbm implementing a mapping interface.  I would use the most natural mapping idioms:

-   for k, v in db.iteritems():
-       print(k, '\t', v)
+   for k in db:
+       print(k, '\t', db[k])

The downside of this example is that it does not explicitely call methods, making the comment about ?Other dictionary methods? strange.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10609>
_______________________________________

From report at bugs.python.org  Thu Dec 16 02:45:01 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 16 Dec 2010 01:45:01 +0000
Subject: [issue10627] Remove usage of deprecated configparser.ConfigParser
	class in the stdlib
In-Reply-To: <1291479066.31.0.42348750803.issue10627@psf.upfronthosting.co.za>
Message-ID: <1292463901.7.0.626605974239.issue10627@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

SafeConfigParser was renamed to ConfigParser in r87299 so this change is no longer necessary.

----------
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10627>
_______________________________________

From report at bugs.python.org  Thu Dec 16 04:55:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 03:55:22 +0000
Subject: [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1292471722.48.0.967817047292.issue9312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I removed one instance of unnecessary markup in r87294 (pointed by Michael Foord on IRC) and made other minor changes in r87296, r87300 and r87302.

Those eight commits are now merged in 3.1 as r87305 and 2.7 as r87308.  Please let me know if you find any merge glitches.  Happily closing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Thu Dec 16 04:56:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 03:56:56 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1292471816.1.0.798181839064.issue8140@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have added versionadded directives that were missing in the doc.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Thu Dec 16 04:59:47 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 16 Dec 2010 03:59:47 +0000
Subject: [issue10710] Is Misc/setuid-prog.c still needed?
In-Reply-To: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>
Message-ID: <1292471987.86.0.905269825784.issue10710@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I say ditch it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10710>
_______________________________________

From report at bugs.python.org  Thu Dec 16 05:48:11 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 16 Dec 2010 04:48:11 +0000
Subject: [issue10714] httpserver request length
In-Reply-To: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>
Message-ID: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

BaseHTTPRequestHandler in http.server does not limit the length of the request line so a malicious client can cause the server to run out of memory with a malicious request.

This patch limits the length to 64K (like Apache) and sends Error 414 if it exceeds this.

----------
components: Library (Lib)
files: httpserver_py3k.patch
keywords: patch
messages: 124106
nosy: rosslagerwall
priority: normal
severity: normal
status: open
title: httpserver request length
type: security
versions: Python 3.2
Added file: http://bugs.python.org/file20074/httpserver_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10714>
_______________________________________

From report at bugs.python.org  Thu Dec 16 05:53:55 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 16 Dec 2010 04:53:55 +0000
Subject: [issue10714] httpserver request length
In-Reply-To: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>
Message-ID: <1292475235.36.0.540501575919.issue10714@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10714>
_______________________________________

From report at bugs.python.org  Thu Dec 16 07:15:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 06:15:42 +0000
Subject: [issue8140] extend compileall to compile single files
In-Reply-To: <1268595693.34.0.197672043314.issue8140@psf.upfronthosting.co.za>
Message-ID: <1292480142.97.0.45584832811.issue8140@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I also added the missing function description.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8140>
_______________________________________

From report at bugs.python.org  Thu Dec 16 07:27:38 2010
From: report at bugs.python.org (Phillip Feldman)
Date: Thu, 16 Dec 2010 06:27:38 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>


New submission from Phillip Feldman <phillip.m.feldman at gmail.com>:

The error message "OSError: [Errno 2] No such file or directory" would be far more helpful if it specified the name of the file or directory that cannot be found.

----------
messages: 124108
nosy: Phillip.M.Feldman
priority: normal
severity: normal
status: open
title: uninformative error message
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Thu Dec 16 07:29:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 06:29:25 +0000
Subject: [issue8233] extend py_compile to compile files from stdin
In-Reply-To: <1269549040.6.0.965737416305.issue8233@psf.upfronthosting.co.za>
Message-ID: <1292480965.19.0.0362627240774.issue8233@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Missing doc added in r87312 and r87311.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8233>
_______________________________________

From report at bugs.python.org  Thu Dec 16 08:38:26 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 16 Dec 2010 07:38:26 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1292485106.91.0.219200931004.issue10611@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> I'd like to fix all these issues by moving the exception handling into a single method and unifying the reporting of failure / error / expected failure / skip test. This will fix all these issues and nicely simplify the implementation.

That sounds good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10611>
_______________________________________

From report at bugs.python.org  Thu Dec 16 08:59:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 16 Dec 2010 07:59:33 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292486373.15.0.898860950939.issue6791@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I just read the whole discussion and it seems that code was in place so that client can tolerant of a BAD HTTP 0.9 Server response.
http://www.w3.org/Protocols/HTTP/OldServers.html

Given that issue10711 talks about removing HTTP/0.9 support (+1 to that), this issue will become obsolete.  I too support removing HTTP/0.9. There are hardly any advantages in keeping it around.

----------
nosy:  -BreamoreBoy
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Thu Dec 16 09:20:12 2010
From: report at bugs.python.org (Yevgeniy)
Date: Thu, 16 Dec 2010 08:20:12 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292487612.71.0.38133661784.issue10692@psf.upfronthosting.co.za>


Yevgeniy <shchemelevev at gmail.com> added the comment:

I found than it is server configuration problem.
When i add variable IMAP_COPABILITY to /etc/courier/imapd-ssl all troubles are gone. Variable did not exported from /etc/courier/imapd, but documentation sad that it imports automatically.
Thank you very much for your attention and help.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Thu Dec 16 09:21:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 16 Dec 2010 08:21:44 +0000
Subject: [issue10711] Rip out HTTP 0.9 support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292487704.88.0.934070313184.issue10711@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

+1 removing HTTP 0.9, and falling back to HTTP 1.0 behavior where ever it was HTTP 0.9. Removing support for response without status (which was acceptable by 0.9) is fine. I reviewed the patch too and it seems good to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Thu Dec 16 09:41:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 08:41:45 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292488905.77.0.431375308371.issue9234@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Georg, I believe this should go in 3.2.
The alias capability is an essential part
of what subparsers are all about and
these absence of aliases would leave them
partially crippled (i.e. unable to emulate
the likes of svn blame/annotate/praise).

Please approve for the second beta.

----------
assignee:  -> georg.brandl
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Thu Dec 16 09:53:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 08:53:40 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292489620.1.0.994363619809.issue10573@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This should get fixed-up before the second beta.

Try to confirm the most common argument ordering using Google's code search to ascertain actual practice in real code.

FWIW, I also tend to use actual/expected and find the reverse to be a form Yoda-speak, "assert 5 == x", "perhaps misread the prophecy was", etc.

----------
nosy: +rhettinger
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Thu Dec 16 09:56:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 08:56:27 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292489787.15.0.964427908482.issue10515@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:04:51 2010
From: report at bugs.python.org (Tan Zong Xuan)
Date: Thu, 16 Dec 2010 09:04:51 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292490291.69.0.256290903882.issue9938@psf.upfronthosting.co.za>


Tan Zong Xuan <tzxrules at gmail.com> added the comment:

I am also trying to use argparse interactively, but in this case by combining it with the cmd module. So I'm doing something like below:

class MyCmd(cmd.Cmd):

    parser = argparse.ArgumentParser(prog='addobject')
    parser.add_argument('attribute1')
    parser.add_argument('attribute2')
    parser.add_argument('attribute3')

    def do_addobject(self, line):
        args = MyCmd.parser.parse_args(line.split())
        newobject = object(args.attribute1, args.attribute2, args.attribute3)
        myobjects.append(newobject)

I'm faced with the same problem that when given invalid input, parse_args exits the program completely, instead of exiting just to the Cmd shell. 

I have the feeling that this use case is sufficiently common such that it would be good if people did not have to override the exit method themselves, and instead an alternative to parse_args was provided that only raises exceptions for the surrounding code to handle rather than exiting the program entirely.

----------
nosy: +ZOMGxuan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:09:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:09:02 +0000
Subject: [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292490542.22.0.267198673516.issue10669@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, whatsnew is not primary documentation -- it should not be the sole or central source of anything except a highlevel overview and examples for the author's choice of selected version differences to highlight. 

A howto document would work best as a central place to list all deprecations and advice on what to do about them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:11:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:11:22 +0000
Subject: [issue10605] ElementTree documentation
In-Reply-To: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za>
Message-ID: <1292490682.2.0.0869751456715.issue10605@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> effbot
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10605>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:12:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:12:56 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1292490776.3.0.787287062062.issue10592@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg122983

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10592>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:13:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:13:35 +0000
Subject: [issue10592] pprint module doesn't work well with OrderedDicts
In-Reply-To: <1291162826.6.0.417417654349.issue10592@psf.upfronthosting.co.za>
Message-ID: <1292490815.18.0.403622850528.issue10592@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10592>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:15:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:15:48 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1292490948.8.0.818979846469.issue6454@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The two principals on the two argument parsing modules both find this unnecessary.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:25:39 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:25:39 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

This is a straight-forward project.

Pydoc currently generated 1990's style html which mixes content and presentation, making it very difficult for users to customize the appearance of the output.

It is full of html like:

<table width="100%%" cellspacing=0 cellpadding=2 border=0 summary="heading">
<tr bgcolor="%s">
<td valign=bottom>&nbsp;<br>
<font color="%s" face="helvetica, arial">&nbsp;<br>%s</font></td
><td align=right valign=bottom
><font color="%s" face="helvetica, arial">%s</font></td></tr></table>
    ''' % (bgcol, fgcol, title, fgcol, extras or '&nbsp;')

    def section(self, title, fgcol, bgcol, contents, width=6,
                prelude='', marginalia=None, gap='&nbsp;'):
        """Format a section with a heading."""
        if marginalia is None:
            marginalia = '<tt>' + '&nbsp;' * width + '</tt>'
        result = '''<p>
<table width="100%%" cellspacing=0 cellpadding=2 border=0 summary="section">
<tr bgcolor="%s">
<td colspan=3 valign=bottom>&nbsp;<br>
<font color="%s" face="helvetica, arial">%s</font></td></tr>
    ''' % (bgcol, fgcol, title)
        if prelude:
            result = result + '''
<tr bgcolor="%s"><td rowspan=2>%s</td>
<td colspan=2>%s</td></tr>
<tr><td>%s</td>''' % (bgcol, marginalia, prelude, gap)

Please convert it to simple, validated HTML with the formatting moved to a simple, validated default style sheet.  Liberally apply div/span elements with class/id attributes as necessary.

----------
components: Library (Lib)
keywords: gsoc
messages: 124119
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Modernize pydoc to use CSS
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:38:30 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 16 Dec 2010 09:38:30 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292492310.02.0.333354965345.issue10715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Normally the filename is part of the error message, as you can see below.
It's possible that some operations omit it, though. Which function were you calling?

>>> open('foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'foo'

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Thu Dec 16 10:41:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 16 Dec 2010 09:41:30 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292492490.4.0.23947096158.issue10715@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Operating systems also return this errno for many, many things unrelated to files. So while we might be able to fix this in some specific cases, in general it's not possible to add file names to all errors.

Once we know your specific case we can see if it's fixable.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Thu Dec 16 11:28:21 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 16 Dec 2010 10:28:21 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292495301.17.0.204687113908.issue10716@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 11:38:47 2010
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 16 Dec 2010 10:38:47 +0000
Subject: [issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1292495927.07.0.690632302295.issue10566@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

I forgot to remove a tempfile and reverted the Cython note at the top. A diff is provided (that should be applied upon the previously submitted patch). It's a diff because I don't have commit rights and svn does not support local commits.

----------
Added file: http://bugs.python.org/file20075/libpython.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Thu Dec 16 11:39:02 2010
From: report at bugs.python.org (Mark Florisson)
Date: Thu, 16 Dec 2010 10:39:02 +0000
Subject: [issue10566] gdb debugging support additions (Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1292495942.28.0.482230332045.issue10566@psf.upfronthosting.co.za>


Changes by Mark Florisson <markflorisson88 at gmail.com>:


Removed file: http://bugs.python.org/file19857/libpython_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Thu Dec 16 11:48:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 16 Dec 2010 10:48:19 +0000
Subject: [issue5625] test_urllib2 fails - urlopen error file not on local host
In-Reply-To: <1238514488.84.0.993697323023.issue5625@psf.upfronthosting.co.za>
Message-ID: <1292496499.59.0.023229390454.issue5625@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Well, ignore my comment on order of ip addresses. It definitely does not matter in this case for test_urllib2.

However, readability does matter again as per my previous explanation, since http://localhost/ was being exercised in the test_file, gethostbyname('localhost') is much better than that return value's [2][0] element.

I overlooked one thing in your first message, namely gethostbyname and gethostbyname_ex()[2] returning completely different ips and turning out to be exclusive. This should not be the case. gethostbyname_ex()[2] should include the ip which was returned by gethostbyname. If it were the case, the test would not have failed as well.

And btw, both these are supposed have similar behavior (The default action is to query named(8), followed by /etc/hosts) only thing is gethostbyname_ex uses the reentrant c function call and is thread-safe.

(You may probably want to identify the problem for the difference in o/p there)

And for this bug report, I am still inclined to having 'localhost' for readability purposes or leaving it as such because the problem seems be elsewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5625>
_______________________________________

From report at bugs.python.org  Thu Dec 16 13:13:00 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 16 Dec 2010 12:13:00 +0000
Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first
	time
Message-ID: <1292501580.01.0.219380098449.issue1633941@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

I guess http://bugs.python.org/issue1195 might be related

----------
nosy: +nvetoshkin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633941>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:07:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Dec 2010 13:07:37 +0000
Subject: [issue10692] imap lib server compabilities
In-Reply-To: <1292242305.39.0.801883549547.issue10692@psf.upfronthosting.co.za>
Message-ID: <1292504857.49.0.575255993491.issue10692@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are welcome.  Glad you were able to solve it.

----------
resolution:  -> invalid
stage: unit test needed -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10692>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:18:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 13:18:30 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292505510.01.0.518068975421.issue6791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, removing 0.9 support doesn't make this obsolete, does it?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:23:47 2010
From: report at bugs.python.org (Jesse Kaukonen)
Date: Thu, 16 Dec 2010 13:23:47 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1292505827.64.0.164132297422.issue9991@psf.upfronthosting.co.za>


Jesse Kaukonen <jesse.kaukonen at gmail.com> added the comment:

I tested the latest release of Python (3.1.3) with Blender and everything worked beautifully. Renderfarm.fi thanks you for fixing this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:48:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:48:41 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292507321.34.0.2817094162.issue9938@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You can always catch SystemExit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:53:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:53:20 +0000
Subject: [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292507600.05.0.313613675551.issue10669@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

PEP 4 and PEP 290 are related to this subject, but not comprehensive, not on docs.python.org, and not tutorial-like.

I think we could try Ezio?s idea.  Sphinx can produce a document containing only version* directives (?make changes?).  If such a document is clear enough and has links to the longer docs, there would be no need to write separate howtos.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:54:37 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 16 Dec 2010 13:54:37 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1292505510.01.0.518068975421.issue6791@psf.upfronthosting.co.za>
Message-ID: <20101216135422.GB4927@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Thu, Dec 16, 2010 at 01:18:30PM +0000, Antoine Pitrou wrote:
> Well, removing 0.9 support doesn't make this obsolete, does it?

It does. Doesn't it? Because I saw in your patch that you fall back on
HTTP 1.0 behaviour when the server does not return a status line and
in which case a Exception will be raise and this issue won't be
observed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:55:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:55:51 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1292507751.4.0.482981686944.issue6454@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I understood Greg?s reply to mean that there was no need for an examples keyword if simple paragraph splitting was added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Thu Dec 16 14:56:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:56:22 +0000
Subject: [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292507782.66.0.288587203069.issue10669@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components:  -2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10669>
_______________________________________

From report at bugs.python.org  Thu Dec 16 15:02:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 14:02:10 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <20101216135422.GB4927@rubuntu>
Message-ID: <1292508126.3689.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It does. Doesn't it? Because I saw in your patch that you fall back on
> HTTP 1.0 behaviour when the server does not return a status line and
> in which case a Exception will be raise and this issue won't be
> observed.

I don't think you understood the issue here. Calling readline() without
a maximum length means the process memory potentially explodes, if the
server sends gigabytes of data without a single "\n".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Thu Dec 16 15:08:59 2010
From: report at bugs.python.org (Dimitrios Pritsos)
Date: Thu, 16 Dec 2010 14:08:59 +0000
Subject: [issue10717] Multiprocessing module Pickling unPickling issues
In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>
Message-ID: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>


New submission from Dimitrios Pritsos <dpritsos at extremepro.gr>:

My name is Dimitrios and I am newbie in python. I am working on a Project (part of my PhD) that is called Synergeticprocessing module. Initially is imitating the multiprocessing built in module but the processes are distributed on a LAN and not Locally. The main issue I have is with Pickle module. And I think I found some kind of BUG in the built in multiprocessing module.

(Synergeticprocessing module is located at GitHub: https://github.com/dpritsos/synergeticprocessing)

Starting with the "BUG". In case someone uses the multiprocessing.Pool of processes he/she has to face the problem of types.MehtodType Impossible pickling. That is you cannot dispatch an class instance method to the to the Process Pool. However, digging in to the Source Code of the module there are few lines that resolve this issue however are not activated or they are faultily activated so they do not work. This is the 'BUG'

@ ....../multiprocessing/forking.py


.
.
.

#
# Try making some callable types picklable
#

from pickle import Pickler
class ForkingPickler(Pickler):
    dispatch = Pickler.dispatch.copy()

    @classmethod
    def register(cls, type, reduce):
        def dispatcher(self, obj):
            rv = reduce(obj)
            self.save_reduce(obj=obj, *rv)
        cls.dispatch[type] = dispatcher

def _reduce_method(m):
    if m.im_self is None:
        return getattr, (m.im_class, m.im_func.func_name)
    else:
        return getattr, (m.im_self, m.im_func.func_name)
ForkingPickler.register(type(ForkingPickler.save), _reduce_method)

def _reduce_method_descriptor(m):
    return getattr, (m.__objclass__, m.__name__)
ForkingPickler.register(type(list.append), _reduce_method_descriptor)
ForkingPickler.register(type(int.__add__), _reduce_method_descriptor)

#def _reduce_builtin_function_or_method(m):
#    return getattr, (m.__self__, m.__name__)
#ForkingPickler.register(type(list().append), _reduce_builtin_function_or_method)
#ForkingPickler.register(type(int().__add__), _reduce_builtin_function_or_method)
.
.
.

The RED lines are not doing the job, for some reason they are not managing to register the GREEN function as a global reduce/pickling function even if you call the registration function into you __main__ script.

The solution I found is just to do this

import copy_reg
import types

def _reduce_method(m):
    if m.im_self is None:
        return getattr, (m.im_class, m.im_func.func_name)
    else:
        return getattr, (m.im_self, m.im_func.func_name)

copy_reg.pickle(types.MethodType, _reduce_method)
.
.
.

Doing that everything works FINE. But ONLY for local methods i.e. the ones that their class is defined on the __main__ script or other import-ed.

In case you want to send something remotely (in an other machine) or to an other __main__ script running separately then you get a message like this:

'module' object has no attribute '<my_class>'

The only way to resolve this is firstly to import a script that has <my_class> defined there and everything works fine.

SO the problems it seems to be that the m.im_class  (look code above) has some attribute __module__ defined as __module__ = '__main__' or something like that. And this is the reason why remote script cannot execute the function. I mean that the _reduce_method() above DOES is pickling the whole CLASS object so there is no reason not to be executed at the remote script. Besides it does as mentioned above in you just import this the user defined class form an other script.


I have already spent about 12 weeks working on building my synergeticPool and resolve the issue of Pickling and only 2 days needed for the code of the Pool and the rest of the time was spent for the Pickling issues, and study all the Class related mechanics of python. That was the reason I ve started digging the multipocessessing module and found this say 'BUG', and finally sent this email.

Best Regards,


Dimitrios

----------
components: None
messages: 124133
nosy: dimitrios
priority: normal
severity: normal
status: open
title: Multiprocessing module Pickling unPickling issues
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10717>
_______________________________________

From report at bugs.python.org  Thu Dec 16 15:12:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 14:12:24 +0000
Subject: [issue10717] Multiprocessing module Pickling unPickling issues
In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>
Message-ID: <1292508744.57.0.497760959453.issue10717@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +asksol, jnoller
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10717>
_______________________________________

From report at bugs.python.org  Thu Dec 16 15:17:40 2010
From: report at bugs.python.org (Jill)
Date: Thu, 16 Dec 2010 14:17:40 +0000
Subject: [issue10718] brand new to programming.  crashes at run
In-Reply-To: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>
Message-ID: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>


New submission from Jill <jillcostello at gmail.com>:

Hello and thanks in advance.  I installed Python 2.7 from the python site onto my MAC with OS X 10.6.4.  After entering my code (which makes me feel humbled and brilliant all at the same time) I am prompted to save, which I do and then when I select run the whole thing crashes.  Error message below.


Process:         Python [14162]
Path:            /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.7.1 (2.7.1)
Code Type:       X86 (Native)
Parent Process:  launchd [149]

Date/Time:       2010-12-16 09:09:15.644 -0500
OS Version:      Mac OS X 10.6.4 (10F569)
Report Version:  6

Interval Since Last Report:          8227 sec
Crashes Since Last Report:           2
Per-App Interval Since Last Report:  1974 sec
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      48621F8F-C51F-400A-8AA8-76DDA70F8973

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000030747369
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
objc_msgSend() selector name: release


Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x9798eedb objc_msgSend + 27
1   com.apple.CoreFoundation      	0x96ec191d _CFAutoreleasePoolPop + 253
2   com.apple.Foundation          	0x9309cdb6 NSPopAutoreleasePool + 76
3   com.apple.Foundation          	0x9309ccde -[NSAutoreleasePool drain] + 130
4   Tk                            	0x0072cf18 XQueryPointer + 2393
5   Tk                            	0x0072d219 Tk_MacOSXSetupTkNotifier + 634
6   Tcl                           	0x005f4aa8 Tcl_DoOneEvent + 310
7   _tkinter.so                   	0x003d75b2 Tkapp_MainLoop + 450
8   org.python.python             	0x000c18e0 PyEval_EvalFrameEx + 26576
9   org.python.python             	0x000c3c7c PyEval_EvalCodeEx + 1996
10  org.python.python             	0x000c15ce PyEval_EvalFrameEx + 25790
11  org.python.python             	0x000c2ba3 PyEval_EvalFrameEx + 31379
12  org.python.python             	0x000c3c7c PyEval_EvalCodeEx + 1996
13  org.python.python             	0x000c3dc7 PyEval_EvalCode + 87
14  org.python.python             	0x000e82fc PyRun_FileExFlags + 172
15  org.python.python             	0x000e8664 PyRun_SimpleFileExFlags + 596
16  org.python.python             	0x00100255 Py_Main + 3365
17  Python                        	0x00001f65 start + 53

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x961f4942 kevent + 10
1   libSystem.B.dylib             	0x961f505c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x961f4519 _dispatch_queue_invoke + 163
3   libSystem.B.dylib             	0x961f42be _dispatch_worker_thread2 + 240
4   libSystem.B.dylib             	0x961f3d41 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             	0x961ed086 select$DARWIN_EXTSN + 10
1   Tcl                           	0x0062a72b Tcl_InitNotifier + 1643
2   libSystem.B.dylib             	0x961fb81d _pthread_start + 345
3   libSystem.B.dylib             	0x961fb6a2 thread_start + 34

Thread 3:
0   libSystem.B.dylib             	0x961f39d2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x961f3f68 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 4:
0   libSystem.B.dylib             	0x961f39d2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x961f3f68 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 5:
0   libSystem.B.dylib             	0x961ce0fa mach_msg_trap + 10
1   libSystem.B.dylib             	0x961ce867 mach_msg + 68
2   com.apple.CoreFoundation      	0x96ec4faf __CFRunLoopRun + 2079
3   com.apple.CoreFoundation      	0x96ec4094 CFRunLoopRunSpecific + 452
4   com.apple.CoreFoundation      	0x96ec9fd4 CFRunLoopRun + 84
5   com.apple.DesktopServices     	0x91b61e13 TSystemNotificationTask::SystemNotificationTaskProc(void*) + 643
6   ...ple.CoreServices.CarbonCore	0x90dc1dee PrivateMPEntryPoint + 68
7   libSystem.B.dylib             	0x961fb81d _pthread_start + 345
8   libSystem.B.dylib             	0x961fb6a2 thread_start + 34

Thread 6:
0   libSystem.B.dylib             	0x961f39d2 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x961f3f68 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x961f3b86 start_wqthread + 30

Thread 7:
0   libSystem.B.dylib             	0x961ed086 select$DARWIN_EXTSN + 10
1   com.apple.CoreFoundation      	0x96f0480d __CFSocketManager + 1085
2   libSystem.B.dylib             	0x961fb81d _pthread_start + 345
3   libSystem.B.dylib             	0x961fb6a2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x17febda0  ebx: 0x96e94bdd  ecx: 0x90b48f80  edx: 0x17febaa3
  edi: 0x30747369  esi: 0x17febda0  ebp: 0xbfffeb48  esp: 0xbfffeb24
   ss: 0x0000001f  efl: 0x00010206  eip: 0x9798eedb   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x30747369

Binary Images:
    0x1000 -     0x1ff7 +Python ??? (???) <51596607-6FF7-D67F-3A8C-2E356F7C2E5F> /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
    0x4000 -   0x142fff +org.python.python 2.7.1, (c) 2004-2008 Python Software Foundation. (2.7.1) <ABD64476-0CA4-162F-9F84-47CE0657A29D> /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x3d3000 -   0x3daff7 +_tkinter.so ??? (???) <81678E64-0547-50B0-EBEA-CBFA43314244> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
  0x3f5000 -   0x3f8ff7 +strop.so ??? (???) <2FD28DAD-4479-79EC-9842-B3C52E3CAF35> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
  0x3fd000 -   0x3fdff7 +_bisect.so ??? (???) <B0893FB6-39BD-F086-94F8-36568CBC3502> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_bisect.so
  0x576000 -   0x648fe7  Tcl 8.5.7 (8.5.7) <A2F55FED-60C5-CFC6-FC2D-B7F620C10E3D> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x661000 -   0x75aff7  Tk 8.5.7 (8.5.7) <9519AEE0-8D83-CBE9-9A99-AE7E2B2CC5FE> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
  0x7c8000 -   0x7cfff7 +_socket.so ??? (???) <62293AFA-3EDE-2269-947C-76849F5BB528> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
  0x7d7000 -   0x7d8ff7 +_functools.so ??? (???) <8B634E9B-420B-892A-25B6-11954BD48DF4> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
  0x7db000 -   0x7dfff7 +_ssl.so ??? (???) <2BB61E6D-DC31-8D06-994B-10B4B5BEBF80> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
  0x7e4000 -   0x7e5ff7 +cStringIO.so ??? (???) <08EBE192-3DC1-CADD-57BB-08574C0C04B1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
  0x7e9000 -   0x7eaff7 +time.so ??? (???) <2AEA478A-A870-63C5-C3D0-EC48A6ECFEDD> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
  0x7ef000 -   0x7f2ff7 +_collections.so ??? (???) <454B6F3A-1EF8-A9B6-EB7C-890A6449338A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
  0x7f7000 -   0x7faff7 +operator.so ??? (???) <9705DADE-C96B-11C8-9BFC-6CA8FF8B5604> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
 0x1a00000 -  0x1a05ff7 +itertools.so ??? (???) <32A1DC96-2F03-4A3B-8296-43B7AD4DAF09> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
 0x1a0d000 -  0x1a0eff7 +_heapq.so ??? (???) <E10B669B-BEDE-5137-A036-33A944341379> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
 0x1a52000 -  0x1a54ff7 +select.so ??? (???) <5563F45B-D2EF-B3A3-3641-33A802EEF45D> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so
 0x1ab9000 -  0x1abaff7 +fcntl.so ??? (???) <3642A8F8-1F0B-C087-CC96-F26F9E800913> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
 0x1abd000 -  0x1ac0ff7 +_struct.so ??? (???) <D34F3B84-F11C-C3FB-8459-271077E27570> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
 0x1ac7000 -  0x1ac9ff7 +binascii.so ??? (???) <6E6BD57A-A222-30BA-25F6-C095448750E6> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
 0x1b8d000 -  0x1b91ff7 +math.so ??? (???) <4AC469C2-630F-871E-A32C-10AC30D84C55> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
 0x1b96000 -  0x1b97ff7 +_hashlib.so ??? (???) <F5BFF380-FA66-6208-78CC-F2D3C34E8040> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
 0x1b9b000 -  0x1b9cff7 +_random.so ??? (???) <7A02D855-38C3-533E-6075-4B82B5CDE359> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
 0x1b9f000 -  0x1ba0ff7 +_locale.so ??? (???) <FFECB439-8A7C-1D3F-1B2B-FE37EEAD0C2F> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
 0x1be3000 -  0x1bf1ff7 +cPickle.so ??? (???) <4D4159DF-3705-8AB2-AE65-8ED1A9BD103E> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
0x8fe00000 - 0x8fe4162b  dyld 132.1 (???) <A4F6ADCC-6448-37B4-ED6C-ABB2CD06F448> /usr/lib/dyld
0x90273000 - 0x9027dfe7  com.apple.audio.SoundManager 3.9.3 (3.9.3) <DE0E0EF6-8190-3F65-6BDD-5AC9D8A025D6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x902c8000 - 0x90371ff7  com.apple.CFNetwork 454.9.8 (454.9.8) <DB2A5C33-E833-1B3A-4DE0-5FF172B2048B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x90372000 - 0x90c52ff7  com.apple.AppKit 6.6.6 (1038.29) <6F28C335-6DC2-AE0E-B79A-F256DBD0BB45> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x90c53000 - 0x90c8bff7  libcups.2.dylib 2.8.0 (compatibility 2.0.0) <76C02F5C-98FD-BD64-B5FB-C698FB76EA25> /usr/lib/libcups.2.dylib
0x90d69000 - 0x90d9aff7  libGLImage.dylib ??? (???) <9340012D-595A-6243-9C97-7D30D76D9D9E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x90d9b000 - 0x910bbfeb  com.apple.CoreServices.CarbonCore 861.13 (861.13) <52803668-3669-36BD-57DD-078FBA835081> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x910fc000 - 0x91114ff7  com.apple.CFOpenDirectory 10.6 (10.6) <3F5A2267-3C89-63A1-724D-3C09538BE092> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x91347000 - 0x913a2ff7  com.apple.framework.IOKit 2.0 (???) <A013B850-6ECB-594A-CBD6-DB156B11871B> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x913a3000 - 0x913f3ff7  com.apple.framework.familycontrols 2.0.1 (2010) <B9762E20-543D-13B9-F6BF-E8585F04CA01> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x91449000 - 0x9144cffb  com.apple.help 1.3.1 (41) <6A5AD406-9D8E-5BAC-51E1-E09AB9A6D159> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x9144d000 - 0x91458ff7  libCSync.A.dylib 543.50.0 (compatibility 64.0.0) <4FA0CE4A-BDE5-0E3D-37F0-03B41F0C2637> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x91459000 - 0x91496ff7  com.apple.SystemConfiguration 1.10.2 (1.10.2) <398BB007-41FD-1A30-26D8-CB86ED5E467E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x91497000 - 0x914a1ff7  com.apple.HelpData 2.0.4 (34) <7F27DBA6-3015-7AFB-D256-AF7C41823E6C> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x917a7000 - 0x91822fe7  com.apple.audio.CoreAudio 3.2.2 (3.2.2) <51D0E2DC-B15F-AF6C-70D8-026DDAD4E2A5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x91867000 - 0x918abfe7  com.apple.Metadata 10.6.3 (507.10) <630494FA-3BB3-EDD3-E10B-8DAAF4831E26> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x9199b000 - 0x91a1dffb  SecurityFoundation ??? (???) <3670AE8B-06DA-C447-EB14-79423DB9C474> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x91a1e000 - 0x91a8dff7  libvMisc.dylib 268.0.1 (compatibility 1.0.0) <B3DEACA1-9375-CF8F-0898-AA2C5F8159DC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x91a8e000 - 0x91b5ffe3  ColorSyncDeprecated.dylib 4.6.0 (compatibility 1.0.0) <8FDB4C40-D453-DA53-2A66-9A53998AB23C> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ColorSync.framework/Versions/A/Resources/ColorSyncDeprecated.dylib
0x91b60000 - 0x91c3bfe7  com.apple.DesktopServices 1.5.7 (1.5.7) <A69072AD-C47E-A00D-4A69-6E46A7FB2119> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x91c3c000 - 0x91c6dff3  libTrueTypeScaler.dylib ??? (???) <7601D717-236D-8F4E-91F5-E69BB2920478> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x91c6e000 - 0x91c6eff7  com.apple.Cocoa 6.6 (???) <5A785062-1ABB-2A54-BAAC-8FEF95275E05> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x91c6f000 - 0x91c6fff7  com.apple.Carbon 150 (152) <9252D5F2-462D-2C15-80F3-109644D6F704> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x91c70000 - 0x91cb6ff7  libauto.dylib ??? (???) <7FE46BC8-ED91-12A7-83D0-2102D37CA32D> /usr/lib/libauto.dylib
0x91cb7000 - 0x91ccbfe7  libbsm.0.dylib ??? (???) <B328FA0A-899C-4FC4-F2AC-2FDC08819CD2> /usr/lib/libbsm.0.dylib
0x91ccc000 - 0x91d15fe7  libTIFF.dylib ??? (???) <9CFF48CC-4852-4D06-17AC-3C947C824159> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x91d7c000 - 0x91d9bff7  com.apple.CoreVideo 1.6.1 (45.5) <567D483E-58F7-54F9-3E6F-FAD3B21FAABF> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x91d9c000 - 0x91da5ff7  com.apple.DiskArbitration 2.3 (2.3) <6AA6DDF6-AFC3-BBDB-751A-64AE3580A49E> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x91da6000 - 0x91dadff3  com.apple.print.framework.Print 6.1 (237.1) <726A7F31-8C27-8403-0016-71E022EDC14C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x91e71000 - 0x91eb2ff7  libRIP.A.dylib 543.50.0 (compatibility 64.0.0) <8BAE1FC1-A478-F151-17C7-2D5DE470AC4F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x91eb3000 - 0x91eb7ff7  libGIF.dylib ??? (???) <3ECD4D2C-40FE-E9A0-A2D2-E36D1C00D3A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x91eb8000 - 0x91ed3ff7  libPng.dylib ??? (???) <36A3D75E-5178-4358-7F02-444E276D61AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x92eff000 - 0x92f14fff  com.apple.ImageCapture 6.0 (6.0) <04BD774A-2A1A-DA87-0885-10A7E8EB3E3F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x92f6e000 - 0x9307aff7  libGLProgrammability.dylib ??? (???) <1B315838-F477-5416-7504-67EC3433AD4A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x93099000 - 0x93309ffb  com.apple.Foundation 6.6.3 (751.29) <E77D3906-99F4-FEF4-FBB0-86FB3C94073E> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x9380c000 - 0x938a4fe7  edu.mit.Kerberos 6.5.10 (6.5.10) <8B83AFF3-C074-E47C-4BD0-4546EED0D1BC> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x938a5000 - 0x93c53fe3  com.apple.RawCamera.bundle 3.3.0 (533) <05A38D21-8556-434C-8BAA-850A6EC99B37> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
0x94783000 - 0x94785ff7  libRadiance.dylib ??? (???) <AB06F616-E3EA-5966-029A-8AA44BBE5B28> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x94787000 - 0x947c9ff7  libvDSP.dylib 268.0.1 (compatibility 1.0.0) <1AE34B00-8A62-1E51-935F-BB3F0E4BE50F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x94831000 - 0x94836ff7  com.apple.OpenDirectory 10.6 (10.6) <27D81AE3-DB56-3872-8CBB-BE88EF5DB3B3> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x94837000 - 0x9483dfff  com.apple.CommonPanels 1.2.4 (91) <CE92759E-865E-8A3B-1488-ECD497E4074D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x94a28000 - 0x94a5efff  libtidy.A.dylib ??? (???) <B1B82CF9-C6B1-5BC0-2E1D-A73840DA3885> /usr/lib/libtidy.A.dylib
0x94a5f000 - 0x94adffeb  com.apple.SearchKit 1.3.0 (1.3.0) <7AE32A31-2B8E-E271-C03A-7A0F7BAFC85C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x94c10000 - 0x94c11ff7  com.apple.TrustEvaluationAgent 1.1 (1) <06484720-AB50-6FD9-B5BF-05F5A640C9E5> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x94c12000 - 0x94c76fff  com.apple.htmlrendering 72 (1.1.4) <0D22B190-513B-7FF6-39FC-9D336285DE08> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x94cb8000 - 0x94d68ff3  com.apple.ColorSync 4.6.3 (4.6.3) <AA1076EA-7665-3005-A837-B661260DBE54> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x94f61000 - 0x94f83fef  com.apple.DirectoryService.Framework 3.6 (621.3) <96E7B3D5-A881-2B02-E97F-6B09461F3C98> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x94f84000 - 0x94f90ff7  libkxld.dylib ??? (???) <322A4B52-8305-3081-6B74-813C3A87A56D> /usr/lib/system/libkxld.dylib
0x950d5000 - 0x950d8ff7  libCoreVMClient.dylib ??? (???) <CA0BA8DC-0159-A808-A300-750358A6970C> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x950d9000 - 0x950f5fe3  com.apple.openscripting 1.3.1 (???) <0E6B81D1-C1BD-1B5F-836F-256E6701B5DE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x95130000 - 0x951c2fe3  com.apple.print.framework.PrintCore 6.2 (312.5) <71C60B1F-2DD7-3321-0DEC-7947ACFBE977> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x951c3000 - 0x951d1ff7  com.apple.opengl 1.6.9 (1.6.9) <4F06C166-00CF-5ACF-77E3-5A960A5E8AD3> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x951d2000 - 0x952d3fe7  libxml2.2.dylib 10.3.0 (compatibility 10.0.0) <BBBC1E4C-024F-3C81-7CB1-70DB451A3E6A> /usr/lib/libxml2.2.dylib
0x9531b000 - 0x9536cff7  com.apple.HIServices 1.8.0 (???) <5FA723CA-B04B-0576-1511-D1FAD5AF0546> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x9536d000 - 0x953b0ff7  libGLU.dylib ??? (???) <2093A1FB-67BD-39E0-CDE5-A97A77BDDBCE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x956a8000 - 0x956b6fe7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <3CE8AA79-F077-F1B0-A039-9103A4A02E92> /usr/lib/libz.1.dylib
0x956b7000 - 0x95aecff7  libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <4D2F47EF-BD32-1E3C-6A0A-438896ADE2BE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x95c4e000 - 0x95c81ff7  com.apple.AE 496.4 (496.4) <23F0DB1F-2856-0091-80AE-BDEF9A4F1731> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x95c82000 - 0x95ee6fef  com.apple.security 6.1.1 (37594) <3F68A006-6B30-85D5-1A75-8D748F72A6D5> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x961cd000 - 0x96373feb  libSystem.B.dylib 125.2.0 (compatibility 1.0.0) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib
0x96374000 - 0x9652efe3  com.apple.ImageIO.framework 3.0.3 (3.0.3) <A93A514B-C1BF-21D0-FB03-CB775DE4FFAA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x96572000 - 0x96596ff7  libJPEG.dylib ??? (???) <5CE96981-6B2A-D15B-4A17-E7BD329095B6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x96597000 - 0x96601fe7  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib
0x96602000 - 0x9669ffe3  com.apple.LaunchServices 362.1 (362.1) <F6789417-5986-60ED-39C5-257C63BD00A7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x966a0000 - 0x966a3ff7  libCGXType.A.dylib 543.50.0 (compatibility 64.0.0) <3B49AED9-0DBA-9D21-F9AC-8784363AD762> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x966a4000 - 0x966a4ff7  com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) <ABF97DA4-3BDF-6FFD-6239-B023CA1F7974> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x9692c000 - 0x96939ff7  com.apple.NetFS 3.2.1 (3.2.1) <E2AFCE90-0DF6-C3B5-A123-222259E985FF> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x96983000 - 0x969c6ff7  com.apple.NavigationServices 3.5.4 (182) <FE19D51B-233A-69EC-9E36-B89D0EA438C1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x969c7000 - 0x969f1ff7  com.apple.shortcut 1.1 (1.1) <08A1868D-FEF4-8FB3-D814-79385DCBEC7D> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x969f2000 - 0x969f2ff7  com.apple.Accelerate 1.6 (Accelerate 1.6) <3891A689-4F38-FACD-38B2-4BF937DE30CF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x969f3000 - 0x96aacfe7  libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <B6F00094-F6DC-2399-C36D-1FAF3525EB44> /usr/lib/libsqlite3.dylib
0x96c89000 - 0x96c8dff7  IOSurface ??? (???) <66E11D8E-CF4B-EFD0-37F9-20177C647021> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x96c8e000 - 0x96d36ffb  com.apple.QD 3.35 (???) <70D824C5-C1DF-A0E7-22EC-533B2C10957A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x96d37000 - 0x96e65fe7  com.apple.CoreData 102.1 (251) <0C2636F3-CCB4-5ED9-1D3E-5AE36BE57071> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x96e88000 - 0x97002fe3  com.apple.CoreFoundation 6.6.3 (550.29) <00373783-3744-F47D-2191-BEEA658F0C3D> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x97003000 - 0x97419ff7  libBLAS.dylib 219.0.0 (compatibility 1.0.0) <9D89FCB3-24C9-8FCF-DB49-27B184AC3222> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x97439000 - 0x9743dff7  libGFXShared.dylib ??? (???) <2D32BDBF-C941-93FD-E233-F03D28DB9E94> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x974bd000 - 0x974f8feb  libFontRegistry.dylib ??? (???) <A102F61F-25D5-001A-20C3-56304C585072> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x974f9000 - 0x97521ff7  libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <12FBE8CB-CC8E-FE8A-7362-C852625C5AAF> /usr/lib/libxslt.1.dylib
0x97522000 - 0x97543fe7  com.apple.opencl 12.1 (12.1) <DA2AC3FA-ED11-2D10-21E9-7BDF4778B228> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x97544000 - 0x97544ff7  com.apple.CoreServices 44 (44) <B9461120-F72A-D28F-D0CF-5647958BD3F9> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x97571000 - 0x976f3fe7  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <2314BD12-0821-75BB-F3BC-98D324CFD30A> /usr/lib/libicucore.A.dylib
0x976ff000 - 0x97743ff3  com.apple.coreui 2 (114) <1A3C3B7F-3837-6477-3114-47F6BFD56CB2> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x97927000 - 0x97988fe7  com.apple.CoreText 3.1.0 (???) <98011243-2CCE-DED0-5326-98DA0CA8577D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x97989000 - 0x97a36fe7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <F237B77D-75A3-7240-931D-4735B91D365F> /usr/lib/libobjc.A.dylib
0x97a37000 - 0x97d9fff7  com.apple.QuartzCore 1.6.2 (227.22) <4288F0D2-0C87-F054-C372-8764B44DE024> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x97da0000 - 0x97daaffb  com.apple.speech.recognition.framework 3.11.1 (3.11.1) <90C38107-AEE7-AE55-5C51-28D129B19BCD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x97df2000 - 0x97e12fe7  libresolv.9.dylib 41.0.0 (compatibility 1.0.0) <751955F3-21FB-A03A-4E92-1F3D4EFB8C5B> /usr/lib/libresolv.9.dylib
0x97ea2000 - 0x97eb6ffb  com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <9F5CE4F7-D05C-8C14-4B76-E43D07A8A680> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x97eb7000 - 0x97eebff7  libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <0B900F26-51C1-7639-346F-24B080AEDAF3> /usr/lib/libssl.0.9.8.dylib
0x97eec000 - 0x97ef2ff7  libCGXCoreImage.A.dylib 543.50.0 (compatibility 64.0.0) <94F66BA6-A4E8-63A4-1B70-EFAA4C75D668> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x97ef3000 - 0x97efeff7  libGL.dylib ??? (???) <B87E0676-F5EF-8DA3-6DEE-13C43B3832A7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x97eff000 - 0x97ff1ff7  libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <D2C86308-F998-C83D-F49B-CD484D4EFE6A> /usr/lib/libcrypto.0.9.8.dylib
0x97ff2000 - 0x987e1557  com.apple.CoreGraphics 1.545.0 (???) <DCED8E1A-7504-C31A-B6EF-98BFF1A61060> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x987e2000 - 0x988acfef  com.apple.CoreServices.OSServices 357 (357) <CF9530AD-F581-B831-09B6-16D9F9283BFA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x98922000 - 0x989ffff7  com.apple.vImage 4.0 (4.0) <D979C8BC-7011-A45C-7141-39FC1043CC87> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x98aad000 - 0x98b48ff7  com.apple.ApplicationServices.ATS 275.11.1 (???) <5FF65EC7-F512-530A-7771-3DE240EE6E43> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x98b60000 - 0x98c8cfff  com.apple.audio.toolbox.AudioToolbox 1.6.3 (1.6.3) <EC38C454-4402-9A96-94ED-40608C9B0326> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x98c95000 - 0x98ce2feb  com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0) <27F3FF53-F818-9836-2101-3E963FE0C0E0> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
0x98ce3000 - 0x98d99ffb  libFontParser.dylib ??? (???) <067DC1A2-764B-41EA-B07E-4205472749B7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x98d9a000 - 0x98d9dfe7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x98f51000 - 0x98f63ff7  com.apple.MultitouchSupport.framework 205.34 (205.34) <813475E3-B323-9405-F758-DDA1F5D63B20> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x98f64000 - 0x98f65ff7  com.apple.audio.units.AudioUnit 1.6.3 (1.6.3) <ED2173F9-15C7-5F90-0B36-3ACAD1E6886C> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x98fa8000 - 0x98fa8ff7  com.apple.vecLib 3.6 (vecLib 3.6) <FF4DC8B6-0AB0-DEE8-ADA8-7B57645A1F36> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x98fbd000 - 0x98fbdff7  com.apple.ApplicationServices 38 (38) <EAF1BC8C-4FD4-4300-B8F7-4B24E49125E2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x98fbe000 - 0x98fbeff7  liblangid.dylib ??? (???) <FCC37057-CDD7-2AF1-21AF-52A06C4048FF> /usr/lib/liblangid.dylib
0x98fbf000 - 0x992e3fef  com.apple.HIToolbox 1.6.3 (???) <0A5F56E2-9AF3-728D-70AE-429522AEAD8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x99493000 - 0x994a3ff7  libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) <E276514D-394B-2FDD-6264-07A444AA6A4E> /usr/lib/libsasl2.2.dylib
0x995af000 - 0x995b1ff7  com.apple.securityhi 4.0 (36638) <38D36D4D-C798-6ACE-5FA8-5C001993AD6B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x99778000 - 0x99826ff3  com.apple.ink.framework 1.3.3 (107) <E215794C-F3E9-C067-8882-9054796DDA8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x99906000 - 0x9992cfff  com.apple.DictionaryServices 1.1.1 (1.1.1) <72D54B80-2D85-5BAB-CBB4-8002E150635D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x9992d000 - 0x9993eff7  com.apple.LangAnalysis 1.6.6 (1.6.6) <97511CC7-FE23-5AC3-2EE2-B5479FAEB316> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0xffff0000 - 0xffff1fff  libSystem.B.dylib ??? (???) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib

Model: MacBookPro7,1, BootROM MBP71.0039.B05, 2 processors, Intel Core 2 Duo, 2.66 GHz, 4 GB, SMC 1.62f6
Graphics: NVIDIA GeForce 320M, NVIDIA GeForce 320M, PCI, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.10.131.16.1)
Bluetooth: Version 2.3.7f1, 2 service, 12 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545050B9SA02, 465.76 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8507, 0x24600000
USB Device: Internal Memory Card Reader, 0x05ac  (Apple Inc.), 0x8403, 0x26100000
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x06600000
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8213, 0x06610000
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0x06500000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0236, 0x06300000

----------
components: IDLE
messages: 124134
nosy: Jill
priority: normal
severity: normal
status: open
title: brand new to programming.  crashes at run
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10718>
_______________________________________

From report at bugs.python.org  Thu Dec 16 15:36:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Dec 2010 14:36:03 +0000
Subject: [issue10718] brand new to programming.  crashes at run
In-Reply-To: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>
Message-ID: <1292510163.34.0.673338745941.issue10718@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10718>
_______________________________________

From report at bugs.python.org  Thu Dec 16 16:29:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 15:29:30 +0000
Subject: [issue10714] httpserver request length
In-Reply-To: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>
Message-ID: <1292513370.45.0.6896495473.issue10714@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. First, there's no need to use multiprocessing here. Threading would be sufficient. Second, you shouldn't use an explicit port number, but instead let the server bind itself to whatever port is available (I think 0 using as the port number achieves that).

----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10714>
_______________________________________

From report at bugs.python.org  Thu Dec 16 16:52:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Dec 2010 15:52:01 +0000
Subject: [issue10719] compileall no longer warns when cli arguments name
	non-existent files
In-Reply-To: <1292514721.24.0.504015013998.issue10719@psf.upfronthosting.co.za>
Message-ID: <1292514721.24.0.504015013998.issue10719@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The introduction of support for compiling individual files broke the previous behavior of compileall, where it would report that it could not turn a directory name into a file list if the named directory did not exist.

A fix would be to reverse the test used to determine whether or not to call compile_file: instead of calling it if the name is not a directory, we should call it if the name is a file, and pass everything else to compile_dir.  This would restore the previous behaviour.

Note that compileall considers not finding a named file/directory as successful compilation, so this is a low priority bug.

----------
keywords: easy
messages: 124136
nosy: r.david.murray
priority: low
severity: normal
stage: unit test needed
status: open
title: compileall no longer warns when cli arguments name non-existent files
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10719>
_______________________________________

From report at bugs.python.org  Thu Dec 16 17:20:36 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 16 Dec 2010 16:20:36 +0000
Subject: [issue10714] httpserver request length
In-Reply-To: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>
Message-ID: <1292516436.27.0.617378506781.issue10714@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

OK, here is an updated patch using threading & 0 as a port number.

----------
Added file: http://bugs.python.org/file20076/httpserver_py3k_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10714>
_______________________________________

From report at bugs.python.org  Thu Dec 16 17:41:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 16:41:38 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292517698.59.0.572599540737.issue10454@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Thu Dec 16 18:06:23 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 16 Dec 2010 17:06:23 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1292508126.3689.2.camel@localhost.localdomain>
Message-ID: <20101216170549.GD7964@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Thu, Dec 16, 2010 at 02:02:10PM +0000, Antoine Pitrou wrote:
> I don't think you understood the issue here. Calling readline() without
> a maximum length means the process memory potentially explodes, if the
> server sends gigabytes of data without a single "\n".

Yeah, I seem to have misunderstood the issue.  Even if the response wa
s an *invalid* one but it was huge data without \n, the readline call
would just explode.

- reading chunked response is doing a readline call too.

Both this need to be addressed by having a limit on reading.

I thought readline() is being called only when parsing headers which
should almost always have CRLF (or at least LF) and thought valid
responses always start with headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Thu Dec 16 18:12:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 17:12:35 +0000
Subject: [issue10714] httpserver request length
In-Reply-To: <1292474891.55.0.351573149453.issue10714@psf.upfronthosting.co.za>
Message-ID: <1292519555.07.0.690040412996.issue10714@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It turns out the test could be simplified a lot by reusing the existing infrastructure. I've committed the modified patch in r87317 (3.2), r87318 (3.1) and r87320 (2.7). Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10714>
_______________________________________

From report at bugs.python.org  Thu Dec 16 18:29:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 17:29: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: <1292520552.15.0.338589411707.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does someone have time to review?  I think this would be a good change for 3.2.

Georg, please lower the priority if you think this can wait for 3.3.

----------
nosy: +georg.brandl
priority: low -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:02:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 18:02:06 +0000
Subject: [issue10720] test_threadsignals hang on FreeBSD 6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The title says it all. This is related to r87292 (issue8844).

----------
components: Library (Lib), Tests
messages: 124141
nosy: db3l, pitrou, rnk
priority: normal
severity: normal
status: open
title: test_threadsignals hang on FreeBSD 6.4
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10720>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:06:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Dec 2010 18:06:25 +0000
Subject: [issue10718] Idle crashes on OSX when source is saved
In-Reply-To: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>
Message-ID: <1292522785.71.0.0374330809472.issue10718@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> After entering my code 

What code did you enter?  Which window did you enter it to?

> I am prompted to save

what exactly did you do before you were "prompted"?   What did the "prompt" look like.  Can you post the screen shots?


I was actually able to produce a similar crash in the following steps:

1. Start idle2.7 from the terminal
2. File > New window
3. Enter 1 + 1 in the new window
4. File > Save (save as test.py)
5. Wait 5-10 seconds

Segmentation fault

----------
nosy: +belopolsky
title: brand new to programming.  crashes at run -> Idle crashes on OSX when source is saved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10718>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:12:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Dec 2010 18:12:29 +0000
Subject: [issue10718] Idle crashes on OSX when source is saved
In-Reply-To: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>
Message-ID: <1292523149.38.0.53956599461.issue10718@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Same behavior when starting /Applications/Python 2.7/IDLE.app in finder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10718>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:20:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Dec 2010 18:20:09 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292523609.76.0.234931751569.issue10716@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I believe Ron has done something along these lines already.  See issue2001.  Committed css file is empty, (see r86971) but I am adding Ron to "nosy" in case he has something in the pipeline.

----------
nosy: +belopolsky, ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:21:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 18:21:45 +0000
Subject: [issue10721] Remove HTTP 0.9 server support
In-Reply-To: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>
Message-ID: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http.server has support for old-style HTTP 0.9 requests ("command path" without a version string). This issue proposes to remove this support, since there are probably no clients around which still issue such requests.

See issue10711 for the client side.

----------
components: Library (Lib)
files: http09server.patch
keywords: patch
messages: 124145
nosy: exarkun, giampaolo.rodola, gregory.p.smith, jhylton, orsenthil, pitrou, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Remove HTTP 0.9 server support
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20077/http09server.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10721>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:22:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 18:22:04 +0000
Subject: [issue10711] Rip out HTTP 0.9 client support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292523724.63.0.846109088579.issue10711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm opening a separate issue (issue10721) for the server side and retargetting this issue to client support. Patch attached.

----------
title: Rip out HTTP 0.9 support -> Rip out HTTP 0.9 client support
Added file: http://bugs.python.org/file20078/removehttp09-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:22:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Dec 2010 18:22:29 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292523749.94.0.169203826869.issue10716@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also the calendar module for an example of a "modern" html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:26:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Dec 2010 18:26:25 +0000
Subject: [issue10710] Is Misc/setuid-prog.c still needed?
In-Reply-To: <1292428417.91.0.430999104384.issue10710@psf.upfronthosting.co.za>
Message-ID: <1292523985.7.0.902570922656.issue10710@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r87323.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10710>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:49:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 18:49:29 +0000
Subject: [issue10721] Remove HTTP 0.9 server support
In-Reply-To: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>
Message-ID: <1292525369.44.0.801995682638.issue10721@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10721>
_______________________________________

From report at bugs.python.org  Thu Dec 16 19:57:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 18:57:54 +0000
Subject: [issue10711] Rip out HTTP 0.9 client support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292525874.84.0.297123078118.issue10711@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch LGTM, modulo warnings.warn calls lacking a stacklevel=2 parameter.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:02:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 16 Dec 2010 19:02:07 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1292383371.7.0.0868416997834.issue8040@psf.upfronthosting.co.za>
Message-ID: <AANLkTin+wNCuUz5oM7JE-zd3ZiDvm1OayK17=mzrckX6@mail.gmail.com>


Daniel Stutzbach <stutzbach at google.com> added the comment:

On Tue, Dec 14, 2010 at 7:22 PM, Ezio Melotti <report at bugs.python.org> wrote:
> If you want to work on this you should also consider that the URLs used on docs.python.org don't necessary match the directory structure present when building the doc locally. For example here it would be:
> .../py3k/library/fractions.html
> .../release31-maint/library/fractions.html
> .../release27-maint/library/fractions.html
> .../release26-maint/library/fractions.html

Will this directory structure change as part of the hg migration?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:04:09 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Dec 2010 19:04:09 +0000
Subject: [issue10718] Idle 2.7.1 from 64-bit installer crashes on OS X when
	source is saved
In-Reply-To: <1292509059.79.0.914872833558.issue10718@psf.upfronthosting.co.za>
Message-ID: <1292526249.59.0.28001804973.issue10718@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Unfortunately, there are some major stability problems with IDLEs that are linked with the Apple-supplied Tcl/Tk 8.5 in OS X 10.6. (See, for instance, Issue9763.) That includes the current python.org 2.7.1 64-bit installer.  The simplest workaround at the moment is to use the other, 32-bit-only 2.7.1 installer for OS X.  It uses the Apple Tcl/Tk 8.4 or ActiveTcl 8.4, if present, neither of which exhibits these kinds of problems.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Crashes upon run after syntax error encountered in OSX 10.5.8
title: Idle crashes on OSX when source is saved -> Idle 2.7.1 from 64-bit installer crashes on OS X when source is saved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10718>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:05:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 19:05:15 +0000
Subject: [issue8040] It would be nice if documentation pages linked to other
	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292526315.43.0.5391193604.issue8040@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, because with Subversion or Mercurial you?re free to clone/checkout any branch in a directory with an arbitrary name.  For the py3k branch, Ezio?s checkout is named py3k but mine is 3.2, there is no way to put knowledge about that in the doc itself.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:16:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 19:16:48 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292527008.64.0.910177181896.issue10680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some more guidelines: http://www.python.org/dev/patches/

----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:16:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Dec 2010 19:16:53 +0000
Subject: [issue10719] compileall no longer warns when cli arguments name
	non-existent files
In-Reply-To: <1292514721.24.0.504015013998.issue10719@psf.upfronthosting.co.za>
Message-ID: <1292527013.22.0.425592227714.issue10719@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r87324.  I've also added a test for the behaviour when no arguments are given, since that wasn't tested before, and removed the sys.path fiddling since it has no effect on subprocess runs.  Oh, and fixed a bug in one of the other tests.

I did not back port this to 2.7.  The tests aren't there, and the risk of breakage seems higher than the benefit of this non-semantic change, for a point release.

----------
keywords: +patch
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
versions:  -Python 2.7
Added file: http://bugs.python.org/file20079/compileall_bad_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10719>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:23:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 19:23:00 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292527380.07.0.365739511863.issue10716@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 20:35:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 16 Dec 2010 19:35:40 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292528140.78.0.880033907483.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Adding an assert as shown in the diff below, makes it easy to reproduce the crash in py3k branch:

$ ./python.exe  crash.py
Assertion failed: (cskipped < 20), function nfc_nfkc, file Modules/unicodedata.c, line 714.
Abort trap

I am attaching jhalcrow's code as crash.py 

===================================================================
--- Modules/unicodedata.c	(revision 87322)
+++ Modules/unicodedata.c	(working copy)
@@ -711,6 +711,7 @@
           /* Replace the original character. */
           *i = code;
           /* Mark the second character unused. */
+          assert(cskipped < 20);
           skipped[cskipped++] = i1;
           i1++;
           f = find_nfc_index(self, nfc_first, *i);

----------
nosy: +belopolsky
Added file: http://bugs.python.org/file20080/crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Thu Dec 16 22:12:55 2010
From: report at bugs.python.org (Ron Adam)
Date: Thu, 16 Dec 2010 21:12:55 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292533975.01.0.683031257617.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I uploaded the css file I used in an experimental version of pydoc.  It may give some useful starting values. 

Before this is done, the old server code should be removed (also for 3.3). (another issue?)  There are two files in the tools/scripts directory that may need attention as well. pydocgui.pyw and pydoc3.

----------
Added file: http://bugs.python.org/file20081/defaultstyle.css

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 22:17:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 21:17:45 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292534265.23.0.378405989084.issue10716@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Those two scripts are just three-liners pydoc launchers.

I disagree about the CSS reset.  Default values and user-set values have a reason for being there, and I share the viewpoint that they should not be reset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 22:42:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 21:42:22 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292535742.52.0.0095876439067.issue10716@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm looking for a deeper fix, all the in-line styling replaced by a stylesheet.  Can you guys work together on bring this to fruition?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Thu Dec 16 23:15:58 2010
From: report at bugs.python.org (Jill)
Date: Thu, 16 Dec 2010 22:15:58 +0000
Subject: [issue10718] Idle 2.7.1 from 64-bit installer crashes on OS X when
	source is saved
In-Reply-To: <1292526249.59.0.28001804973.issue10718@psf.upfronthosting.co.za>
Message-ID: <AANLkTikZXQxxDd4ZZKsJnWZw1t8P8fj74ofY78ZvyCV=@mail.gmail.com>


Jill <jillcostello at gmail.com> added the comment:

*Thanks Ned.  I'll give this a try.  Jill
*
On Thu, Dec 16, 2010 at 2:04 PM, Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at acm.org> added the comment:
>
> Unfortunately, there are some major stability problems with IDLEs that are
> linked with the Apple-supplied Tcl/Tk 8.5 in OS X 10.6. (See, for instance,
> Issue9763.) That includes the current python.org 2.7.1 64-bit installer.
>  The simplest workaround at the moment is to use the other, 32-bit-only
> 2.7.1 installer for OS X.  It uses the Apple Tcl/Tk 8.4 or ActiveTcl 8.4, if
> present, neither of which exhibits these kinds of problems.
>
> ----------
> resolution:  -> duplicate
> status: open -> closed
> superseder:  -> Crashes upon run after syntax error encountered in OSX
> 10.5.8
> title: Idle crashes on OSX when source is saved -> Idle 2.7.1 from 64-bit
> installer crashes on OS X when source is saved
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10718>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20082/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10718>
_______________________________________
-------------- next part --------------
<font color="#666666"><font size="2"><font face="trebuchet ms,sans-serif"><b>Thanks Ned. ??I&#39;ll give this a try. ??Jill<br></b></font></font></font><br><div class="gmail_quote">On Thu, Dec 16, 2010 at 2:04 PM, Ned Deily <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Ned Deily &lt;<a href="mailto:nad at acm.org">nad at acm.org</a>&gt; added the comment:<br>
<br>
Unfortunately, there are some major stability problems with IDLEs that are linked with the Apple-supplied Tcl/Tk 8.5 in OS X 10.6. (See, for instance, Issue9763.) That includes the current <a href="http://python.org" target="_blank">python.org</a> 2.7.1 64-bit installer. ??The simplest workaround at the moment is to use the other, 32-bit-only 2.7.1 installer for OS X. ??It uses the Apple Tcl/Tk 8.4 or ActiveTcl 8.4, if present, neither of which exhibits these kinds of problems.<br>


<br>
----------<br>
resolution: ??-&gt; duplicate<br>
status: open -&gt; closed<br>
superseder: ??-&gt; Crashes upon run after syntax error encountered in OSX 10.5.8<br>
title: Idle crashes on OSX when source is saved -&gt; Idle 2.7.1 from 64-bit installer crashes on OS X when source is saved<br>
<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/issue10718" target="_blank">http://bugs.python.org/issue10718</a>&gt;<br>
_______________________________________<br>
</blockquote></div><br>

From report at bugs.python.org  Thu Dec 16 23:17:39 2010
From: report at bugs.python.org (Jason Scheirer)
Date: Thu, 16 Dec 2010 22:17:39 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292537859.17.0.73727280269.issue1449496@psf.upfronthosting.co.za>


Jason Scheirer <jason.scheirer at gmail.com> added the comment:

The patch is a simple tweak to the Visual Studio project's compiler settings. Seems quite innocuous, nothing broke in the Python harness or our internal harnesses (at ESRI) by enabling this.

----------
keywords: +patch
nosy: +Jason.Scheirer
status: pending -> open
Added file: http://bugs.python.org/file20083/Issue1449496.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Thu Dec 16 23:40:22 2010
From: report at bugs.python.org (Ron Adam)
Date: Thu, 16 Dec 2010 22:40:22 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292539222.63.0.225916133332.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Eric, most of what's in that file is what I figured out by trial and error in order to get it to work on the different browsers at that time. (about 3 years ago.)  You are probably more experienced with css than I am, so you are more than welcome to update and change anything in there. :-)

What do you think about starting with a set of static html pages to get the css and html to work nice, and then only after that is done, edit pydoc to generate those pages.  That should get us mostly there, and simplify what needs to be done in pydoc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 00:13:31 2010
From: report at bugs.python.org (T Rink)
Date: Thu, 16 Dec 2010 23:13:31 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>


New submission from T Rink <tr03 at jm.rinkleff.com>:

Hi. 
My problem is that this evening, the message "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection." appears after I hit F5 to run a file I am editing.

The program briefly worked on and off ... but after ca. 10 minutes it stopped for good. 

I have tried searhcing for solutions, but found nothing that seems to work. 

CONFIGURATION:
   Windows Vista 32
   Python 2.7 (downloaded a week ago)
   New User to Python. Amatuer/Hobby Programmer 

SOLUTIONS I HAVE TRIED
-Tried solution "kill process in task manager". No effect. Process was usually already closed by me anyway, but killing it did not help either. 

-Tried solution "repair via .MSI" file. No change.

-Tried to tell Windows Firewall to ignore python and pythonw, that they were acceptable. No change.  

-Would prefer not to "Scrap IDLE" as I just started! (Also I do not want to write Python only in Notepad and use command lines. As much as I love the command line, I do not want that anymore)

-Started to try to use workaround "-n" flag when starting IDLE. 
  a) I would prefer a Solution and not a Workaround that hinders the program before I am started.  
  b) I am new to Python and Idle. Windows Vista hides the links, it is not clear to me how Python is setup and I am still working on understanding how Python operates ... that is pain enough at the moment....

REQUEST:
 -Either a useful suggestion to get IDLE to work properly and as it should. 
 -Or a good recommendation for a universal and Idiot-Friendly alternative Python programming environment. It should be simple, user-friendly, reliable and suitable for novices to experiment (i.e. no complicated setup!) 

(FYI:I spent two years learning Java, and finally canned it, because I got sick of spending my free-time trying to debug and decipher workarounds to what should have been a simple solution! grrrrrrr!)

Thanks to any who can help.

----------
components: Windows
messages: 124163
nosy: plovet
priority: normal
severity: normal
status: open
title: IDLE's subprocess didnit make connection ..... Python 2.7
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________

From report at bugs.python.org  Fri Dec 17 00:34:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 23:34:02 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292542442.5.0.161959123614.issue10716@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

A good procedure is to start afresh with an empty, embedded style sheet and replace the html styling attributes one at a time, while keeping the overall look and feel the same.   At the end of the process the embedded style sheet can be converted to external.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:07:23 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 00:07:23 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

The "Built-in Exceptions" page of the Python 2.7 documentation is missing descriptions for BufferError, IndentationError, and TabError.

I've gone ahead and added a brief description of each error to the page.

----------
assignee: docs at python
components: Documentation
files: exceptions.rst
messages: 124165
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Undocumented built-in exceptions
versions: Python 2.7
Added file: http://bugs.python.org/file20084/exceptions.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:15:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 00:15:34 +0000
Subject: [issue10721] Remove HTTP 0.9 server support
In-Reply-To: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>
Message-ID: <1292544934.25.0.524938889943.issue10721@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The question really is whether we want or want not to support RFC 1945 (i.e HTTP/1.0). If we want to support it, we also must comply to section 3.1, which says

 The version of an HTTP message is indicated by an HTTP-Version field
 in the first line of the message. If the protocol version is not
 specified, the recipient must assume that the message is in the
 simple HTTP/0.9 format.

If we then choose to not support HTTP/0.9 (after recognizing that the message is HTTP/0.9), we must then reject the request. According to RFC 2145, we then may send back error 505 (HTTP version not supported).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10721>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:19:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 17 Dec 2010 00:19:09 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1292545149.15.0.061493271366.issue9990@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> That's because the new buffer protocol doesn't define ownership of
> Py_buffer structs. As a result, nothing can be assumed at to which
> piece of code is responsible for allocation and deallocation of
> related memory areas (such as shapes and strides arrays).

I was just chatting to Travis about this;  he suggested that the 'internal' field of the Py_buffer struct might be used to record who's responsible for deallocation of shape and stride arrays.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:24:28 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 00:24:28 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292545468.64.0.335235476332.issue10723@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

Just realized I previously attached the entire file. Here is the diff instead.

----------
keywords: +patch
Added file: http://bugs.python.org/file20085/exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:26:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 00:26:28 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292545588.71.0.643256961359.issue10723@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:27:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 00:27:28 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292545648.15.0.907547845419.issue1449496@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:27:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 00:27:47 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292545667.53.0.315944815588.issue1449496@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: unit test needed -> 
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:44:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 00:44:33 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292546673.06.0.391388764062.issue1449496@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm rejecting this as "won't fix". Users having the underlying problem (i.e. need more than 2GB of heap) really should switch to a 64-bit installation. The risk of something breaking is just not worth it.

That testing showed no issues is not convincing at all. Existing test suites will likely not exercise critical code paths wrt. this change, which are issues caused by some objects potentially exceeding 2GB in 32-bit mode. This might not even be Python core objects, but may be objects in an extension module.

----------
resolution: out of date -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Fri Dec 17 01:56:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Dec 2010 00:56:32 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292547392.68.0.848876346911.issue10254@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"Ooops", sorry. I just applied the patch suggested by Marc-Andre Lemburg in msg22885 (#1054943). As the patch worked for the examples given in Unicode PRI 29 and the test suite passed, it was enough for me. I don't understand the normalization code, so I don't know how to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 02:15:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 01:15:27 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292548527.72.0.735957897786.issue10454@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a proposed patch to both docs and help output.  The help output now looks like this:

usage: compileall.py [-h] [-l] [-f] [-q] [-b] [-d DESTDIR] [-x REGEXP]
                     [-i FILE]
                     [FILE|DIR [FILE|DIR ...]]

Utilities to support installing Python libraries.

positional arguments:
  FILE|DIR    zero or more file and directory names to compile; if no
              arguments given, defaults to the equivalent of -l sys.path

optional arguments:
  -h, --help  show this help message and exit
  -l          don't recurse into subdirectories
  -f          force rebuild even if timestamps are up to date
  -q          output only error messages
  -b          use legacy (pre-PEP3147) compiled file locations
  -d DESTDIR  directory to prepend to file paths for use in compile time
              tracebacks and in runtime tracebacks in cases where the source
              file is unavailable
  -x REGEXP   skip files matching the regular expression. The regexp is
              searched for in the full path to each file considered for
              compilation.
  -i FILE     add all the files and directories listed in FILE to the list
              considered for compilation. If "-", names are read from stdin.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20086/compileall_help.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Fri Dec 17 02:22:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 01:22:01 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1292548921.98.0.976220645211.issue10722@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +terry.reedy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________

From report at bugs.python.org  Fri Dec 17 02:25:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 01:25:23 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1292549123.48.0.834556423019.issue10722@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Perhaps Terry will have some advice (I've added him as nosy), but you may have better luck asking on the python mailing list (see mail.python.org for list of lists) or its linked newsgroup comp.lang.python, or on the #python irc channel (though they may tell you to dump Idle, depending on who is in channel at the time :)

It is not likely that what you are experiencing is an actual bug in Ptyhon, since Idle on windows works for lots of people.  However understanding your problem and its solution might help us make the Idle experience more friendly, so I'll leave it to Terry to decide how he wants to handle this.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________

From report at bugs.python.org  Fri Dec 17 02:34:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 01:34:52 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292549692.05.0.442901398789.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The logic suggested by Martin in msg120018 looks right to me, but the whole code seems to be unnecessarily complex.  (And comb1==comb may need to be changed to comb1>=comb.) I don't understand why linear search through "skipped" array is needed.  At the very least instead of adding their positions to the "skipped" list, used combining characters can be replaced by a non-character to be later skipped.  A better algorithm should be able to avoid the whole issue of "skipping" by properly computing the length of the decomposed character.  See internalCompose() at http://www.unicode.org/reports/tr15/Normalizer.java.

I'll try to come up with a patch.

----------
assignee:  -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 03:02:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 02:02:33 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1292551353.4.0.180318766594.issue10542@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Fri Dec 17 03:13:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 02:13:49 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1292022566.21.0.51776102591.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTinHHweu3LFWnCxsXHNdKCz0icp8T2i1P7Tdzf-C@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Dec 10, 2010 at 6:09 PM, Daniel Stutzbach
<report at bugs.python.org> wrote:
..
> The second check for surrogates in Py_UNICODE_PUT_NEXT is necessary, unless you can prove that
> Py_UNICODE_SOME_TRANSFORMATION will never transform characters < 0x10000 into characters >
> 0x10000 or vice versa.
>
> Can we prove will always be the case, for current and future versions of Unicode, for all or almost-all of the
> transformations we care about?
>
Certainly not for all, but for some important transformations, I
believe Unicode Standard does promise that the transformation  maps
BMP to BMP and supplements to supplements.  For example case folding
and normalization are two important examples.

> Answering that question and figuring out what to do about it are probably more trouble than it's worth.
> ?If a particularly point proves to be a bottleneck, we can always specialize the code there later.

Agree.  It is even more likely that the applications that have to deal
with lots of supplementary characters will be better off using a wide
unicode build rather than such specialization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Fri Dec 17 03:51:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 02:51:37 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1292554297.27.0.557526957606.issue9824@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a patch against py3k with test.  If I'm understanding the issue correctly, this looks like a pretty safe change.

----------
nosy: +r.david.murray
stage:  -> patch review
Added file: http://bugs.python.org/file20087/cookies_extra_coding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:06:51 2010
From: report at bugs.python.org (Ron Adam)
Date: Fri, 17 Dec 2010 03:06:51 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292555211.37.0.668400612651.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I think that's how I ended up with the style sheet I uploaded.  It works, but it can be a slow process.

Another factor is the pydoc server will reread an external style sheet on browser refreshes. So you can see the results of style sheet changes without restarting pydoc. If it's embedded, you need to edit the program and restart everything each time.

I was thinking that I may still be able to make a set of static html files that go along with that style sheet.  Then we can adjust the css class names and make other changes, then use that as a guide for replacing the html.

Eric, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:32:36 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Dec 2010 03:32:36 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292556756.95.0.853022329702.issue10716@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The uploaded stylestyle is *much* bigger than I expected.  There should be no more than a one-to-one correspondence.  With inheritance, perhaps even fewer entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:33:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 03:33:51 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1292556831.49.0.624167864704.issue2193@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Seems like this really needs a strict and a lax mode.  Perhaps a BrowserCookie class that implements the relaxed rules?

That would make this a feature request, though, and so nothing would happen until 3.3, which would be unfortunate.

It is certainly possible to create a more relaxed version for your own use.  It seems to me that (untested):

class BrowserCookie(BaseCookie):

    def set(self, key, val, coded_val, LegalChars=_LegalChars+':'):
        super().set(key, val, coded_val, LegalChars)

would do most of what And Clover wants (not adding or stripping quotes or doing backslash quoting or encoding, accepting : in key names (and more characters could be added; the regex in the parsing step is fairly liberal)).

Making further relaxations is difficult without poking in to module internals, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:41:41 2010
From: report at bugs.python.org (Ron Adam)
Date: Fri, 17 Dec 2010 03:41:41 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292557301.62.0.895599699555.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Ok, I just looked at them again, I didn't remember how different it was.  They probably won't be much help other than maybe seeing how some things could be done. Here's a zip file of some saved pages, so you can take a look.

----------
Added file: http://bugs.python.org/file20088/pydoc sample html files.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:42:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 03:42:47 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1292557367.83.0.207902705179.issue9011@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Mark, are you still planning to do something for 3.1/2.7, or should this be closed?

----------
nosy: +r.david.murray
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:42:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Dec 2010 03:42:56 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292557376.63.0.683131239845.issue10716@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The CSS also has a validation error, some warnings and could be written better IMHO (specifically I don't like the placement of the {}).

I also don't believe that extensive CSS resets are useful -- they usually just lead to lot of redefining. I usually limit myself to * { margin: 0; padding: 0; } and possibly specify specific values when necessary. Minor differences with different browsers can be perfectly fine in lot of cases.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 04:56:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Dec 2010 03:56:12 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1292558172.15.0.762013468308.issue9990@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The PEP is quite clear that the object providing the buffer owns those fields. Last time I checked, the memoryview implementation appeared broken because it didn't respect that ownership (and created the potential for confusion on the topic).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Fri Dec 17 05:57:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 17 Dec 2010 04:57:21 +0000
Subject: [issue9721] urlparse.urljoin() cuts off last base character with
	semicolon at url start
In-Reply-To: <1283232058.13.0.308353601536.issue9721@psf.upfronthosting.co.za>
Message-ID: <1292561841.39.0.281830857465.issue9721@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r87329, r87330 and r87331. Thanks for the patch Wes, that was proper.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Fri Dec 17 06:05:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 17 Dec 2010 05:05:54 +0000
Subject: [issue10721] Remove HTTP 0.9 server support
In-Reply-To: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za>
Message-ID: <1292562354.93.0.413947374021.issue10721@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

If a client sends a request without specifying the version, GET /, then the Python server should behave like other common servers are behaving, namely support rfc 1945 for HTTP 1.0 spec and return the response without headers.

Removing the HTTP 0.9 from the http.client is okay. But punishing *any client* for not sending the correct request is not so desirable, especially when there are other servers which are lenient to his behavior for whatever reasons.

So, I am not a firm +1 to this. We should arrive a conclusion and then go about with the change. Martin's point is valid here too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10721>
_______________________________________

From report at bugs.python.org  Fri Dec 17 06:32:48 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 17 Dec 2010 05:32:48 +0000
Subject: [issue4493] urllib2 doesn't always supply / where URI path component
	is empty
In-Reply-To: <1228250772.41.0.047917224679.issue4493@psf.upfronthosting.co.za>
Message-ID: <1292563968.63.0.826430500775.issue4493@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Wes, I forgot to address your last comment. 

HTTPClient follows HTTP Spec for requests and responses. When it is used, the request is on the PATH and the code there checks if the path does not exist does a request on '/'. It is not appropriate to pass Invalid URLS to httpclient the Invalid url handling and corrections to that are handled at the much higher level. That's why I made those changes in urllib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4493>
_______________________________________

From report at bugs.python.org  Fri Dec 17 06:45:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 05:45:41 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292564741.91.0.159683784811.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue10254.diff, is essentially Martin's code from msg120018 and Part3 tests from NormalizationTest.txt.

Since this bug exposes a buffer overflow condition, I think it qualifies as a security issue, so I am adding 2.6 to versions.

Passing Part3 tests and not crashing on crash.py is probably good enough for a commit, but I don't have a proof that length 20 skipped buffer is always enough.  As the next step, I would like to consider an alternative algorithm that would not require a "skipped" buffer.

----------
keywords: +patch
stage:  -> commit review
versions: +Python 2.6
Added file: http://bugs.python.org/file20089/issue10254.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 08:40:38 2010
From: report at bugs.python.org (sean216)
Date: Fri, 17 Dec 2010 07:40:38 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>


New submission from sean216 <taoyuan-216 at 163.com>:

when use socket.close to close the telnet connection, in normal usage the tcp disconnect will be (socket.close send the TCP FIN)

      TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

  6.  (2 MSL)
      CLOSED                                                      
but sometimes socket.close will send TCP RST to disconnect the telnet and with wrong sequence number. This kind of RST will be considering as Network RST attack, and this packet will be dropped, the telnet connection will still established and cannot be closed.
Seems python socket.close has some issues.

    def close(self):
        self._sock = _closedsocket()
        dummy = self._sock._dummy
        for method in _delegate_methods:
            setattr(self, method, dummy)
    close.__doc__ = _realsocket.close.__doc__

----------
components: Library (Lib)
files: telnet_unnormal RST.pcap
messages: 124187
nosy: sean216
priority: normal
severity: normal
status: open
title: socket.close close telnet with RST
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file20090/telnet_unnormal RST.pcap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Fri Dec 17 08:41:11 2010
From: report at bugs.python.org (sean216)
Date: Fri, 17 Dec 2010 07:41:11 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292571671.81.0.897583465334.issue10724@psf.upfronthosting.co.za>


Changes by sean216 <taoyuan-216 at 163.com>:


Added file: http://bugs.python.org/file20091/normal RST and fin.pcap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Fri Dec 17 08:44:48 2010
From: report at bugs.python.org (sean216)
Date: Fri, 17 Dec 2010 07:44:48 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292571888.12.0.689126403738.issue10724@psf.upfronthosting.co.za>


sean216 <taoyuan-216 at 163.com> added the comment:

def close(self):
        self._sock = _closedsocket()
        dummy = self._sock._dummy
        for method in _delegate_methods:
            setattr(self, method, dummy)
    close.__doc__ = _realsocket.close.__doc__

socket.close function use Python25\DLLs\_socket.pyd, how to get _socket.pyd sorce code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Fri Dec 17 09:23:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 08:23:00 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1292547392.68.0.848876346911.issue10254@psf.upfronthosting.co.za>
Message-ID: <4D0B1DCD.40600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 17.12.2010 01:56, schrieb STINNER Victor:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> "Ooops", sorry. I just applied the patch suggested by Marc-Andre
> Lemburg in msg22885 (#1054943). As the patch worked for the examples
> given in Unicode PRI 29 and the test suite passed, it was enough for
> me. I don't understand the normalization code, so I don't know how to
> fix it.

So lacking a new patch, I think we should revert the existing change
for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 09:29:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 08:29:41 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <4D0B1DCD.40600@v.loewis.de>
Message-ID: <4D0B1F70.2040907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So lacking a new patch, I think we should revert the existing change
> for now.

Oops, I missed that Alexander has proposed a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 09:47:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 08:47:00 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1292549692.05.0.442901398789.issue10254@psf.upfronthosting.co.za>
Message-ID: <4D0B2381.7070408@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The logic suggested by Martin in msg120018 looks right to me, but the
> whole code seems to be unnecessarily complex.  (And comb1==comb may
> need to be changed to comb1>=comb.) I don't understand why linear
> search through "skipped" array is needed.  At the very least instead
> of adding their positions to the "skipped" list, used combining
> characters can be replaced by a non-character to be later skipped.

The skipped array keeps track of what characters have been integrated
into a base character, as they must not appear in the output.
Assume you have a sequence B,C,N,C,N,B (B: base character, C: combined,
N: not combined). You need to remember not to output C, whereas you
still need to output N. I don't think replacing them with a
non-character can work: which one would you chose (that cannot also
appear in the input)?

The worst case (wrt. cskipped) is the maximum number of characters that
can get combined into a single base character. It used to be (and I
hope still is) 20 (decomposition of U+FDFA).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 09:48:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 08:48:38 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1292564741.91.0.159683784811.issue10254@psf.upfronthosting.co.za>
Message-ID: <4D0B23E4.9060205@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Passing Part3 tests and not crashing on crash.py is probably good
> enough for a commit, but I don't have a proof that length 20 skipped
> buffer is always enough.

I would agree with that. I still didn't have time to fully review the
patch, but assuming it fixes the cases in msg119995, we should proceed
with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 10:07:17 2010
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 17 Dec 2010 09:07:17 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292576837.47.0.0772024114669.issue10724@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> but sometimes socket.close will send TCP RST to disconnect the telnet and with wrong sequence number

This is called a a "half-duplex" TCP close sequence. Your application is probably closing the socket while there are still data in the receive socket buffer (i.e. unread), so the TCP/IP stack sends a RST to inform the remote end that data has been lost. See RFC 1122 section 4.2.2.13.
Note that in your sample capture, I don't see any invalid sequence/ack number.
Your application should probably not close the connection at this time.

> This kind of RST will be considering as Network RST attack, and this packet will be dropped, the telnet connection will still established and cannot be closed.

There you firewell is broken. Sending a RST in this context is perfectly valid.

As far as I know, this issue is due to your application and firewall settings, and not to Python. Furthermore, Python just calls the underlying close(2) syscall, so even if there were an issue, it's an OS one, nothing Python could do about it.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Fri Dec 17 10:21:42 2010
From: report at bugs.python.org (Finkregh)
Date: Fri, 17 Dec 2010 09:21:42 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1292577702.96.0.233165762684.issue1195@psf.upfronthosting.co.za>


Changes by Finkregh <finkregh at mafia-server.net>:


----------
nosy: +Finkregh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Fri Dec 17 10:48:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Dec 2010 09:48:34 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Nick, can you look at this?

----------
assignee: ncoghlan
components: Library (Lib)
files: sized_cache.diff
keywords: patch
messages: 124194
nosy: ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Better cache instrumentation
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file20092/sized_cache.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Fri Dec 17 12:47:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Dec 2010 11:47:04 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292586424.57.0.840815118119.issue10716@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Raymond]
> I'm looking for a deeper fix, all the in-line styling replaced by a
> stylesheet.  Can you guys work together on bring this to fruition?
When I talked about the CSS reset, I was referring to a precise part of the file proposed by Ron, so we?re already discussing together :-)

I wonder how desirable it is to preserve the look and feel of the pages.  We all agree on externalizing the CSS and add a way for the users to add their own stylesheet; why not take the opportunity to also improve the style?  Huge blocks of colors are not that attractive to me :)

Regarding workflow, I?d find easier to start from bare HTML that works nice (yes, I test with w3m) and then add style.  Technically, I?d like to maintain the HTML as a small set of files (in pydoc_data) containing fragments of HTML with placeholders ({} or $): That?s easy to edit, to validate (a very simple script can put the fragments together) and to use.

I agree that the CSS file should be as short as possible (in content), but not too short (in file size).  For example, trailing commas in properties and brackets on their own line will allow nice diffs, just like Python.

(I won?t have much time for Python in December, but we have a lot of time before 3.3b1 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Fri Dec 17 13:17:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 17 Dec 2010 12:17:24 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When one runs ?pydoc with?, the output is a block of text marked up with reST.  It would be more helpful to render it as text or HTML thanks to a minimal reST parser and transformer.

In http://mail.python.org/pipermail/python-dev/2010-July/101563.html, Martin Geisler (Mercurial dev) said:

?We're using light-weight ReST markup in the Mercurial help texts and
transform it into straight text upon display in the terminal.

We want no external dependencies for Mercurial, so I wrote a "mini ReST"
parser in about 400 lines of code. It cheats a lot and can only handle
simple constructs...? [A few messages later] ?I would be happy to relicense it under the Python license.?

So, proposed battle plan:
1) Agree this feature request is desirable.

2) Agree on the inclusion of mg?s minirst, which provides an reST parser and a plain text formatter.

3) Add an HTML formatter.

4) Wire minirst into pydoc.

----------
messages: 124196
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: pydoc: don?t display raw reST in keyword help
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 13:23:51 2010
From: report at bugs.python.org (Velko Ivanov)
Date: Fri, 17 Dec 2010 12:23:51 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292588631.48.0.570795744643.issue2736@psf.upfronthosting.co.za>


Velko Ivanov <vivanov at ivanov-nest.com> added the comment:

I'm very disappointed by the outcome of this discussion.

You are committing the biggest sin of modern times - instead of promoting the obtaining and usage of knowledge to solve things, you place restrictions to force the dumbheads into not doing mistakes. The big problem with that is that you can never foresee all usecases and all possible mistakes, thus you will always be sorrily bitten by dumbheads. What does that make of you?

Let me present you a situation - I have a system that passes data via JSON, datetime object is not JSON serializable. For few other reasons, like the epoch and float secs since epoch being defacto standard, and the fact that I absolutely make sure at-the-source that my timestamps are UTC and lack zone awareness, and the fact that I'm not going to display those, but only use them for comparison, and that I'm not going to do historical things and calculations and I don't actually need nanosecond precision, just a tenth of the second, and I'm fine with always using the '<' and '>', not the '==', and the fact that 90% of the cases when use datetimes I have exactly the same requirements and it has always been working fine for me - I choose the lightweight float representation at the one side of the system.
In the SQL DB I use tz unaware timestamps, not floats and my DB access layer returns datetime objects and I prefer them at this end of the system. So I only need to serialize the datetime object. Well, as a matter of fact I have a JSON object serialization already in place for some of my objects, but I do not need that for tz unaware datetimes.
So I look for a method that makes a float from a datetime, which I'm used to in PHP, Java, .NET, C, SQL and you name it. And I'm 2 hours into reading about time, datetime and calendar modules and I still haven't even invented the obscure time.mktime(dt.timetuple())+dt.microseconds*1e-6 . And to even think that this creates a timetuple internally ? I hate it instantly and I dismiss the possibility that the API could be so wrong and I keep searching -> on the internets -> which brings me here where all my illusions are finally buried into the dust.

2 Hours for something, that only needs a few warning lines in the docs?
Ok, the ultimately right thing is to actually serialize the datetime object and rework my other end of the system to use dt instead of float .. maybe .. but not now - now I'm only testing an idea for something completely different and I only need faithful and dutiful Python to give me a float from datetime so I can check something.
I love Python for being simple, logical and consistent and for giving me the tools and not telling me what to do with them. 
Not today ... Today Python goes - 'Here is your hammer, but you can not use it to hit straight down. If you hit straight down, and you are using a forge, and you miss your object and hit the forge instead, the hammer could ricochet and hit you back on the forehead, so you can't use it that way. As a matter of fact, there is a gyroscopic sensor embedded in the handle of the hammer and if you try to hit with an angle that is close to 90 degrees, it will detach the head of the hammer from the handle and prevent you from eventually endangering yourself' and I'm like 'WTF??! I'm nailing a nail into a wooden plank!'

Now I'm going to use the obscure one liner and hate it, because it is simply wrong and only someone that doesn't care of implementation detail might think it equal to a proper solution.
The worst thing is, that I learned today, that if I ever need operations with tz aware dates and time intervals in Python, I should actually send an SQL query for that, because my DB has a clean, simple and COMPLETE date/time API that works seamlessly. Yours is a jungle and I see you being asked to include a ready made patch to output a float from a dt, to which you respond by adding a locatime() method 2 years later. 
You seriously think, that #9527 solves this? I don't even see a connection.

With #9527 in the python library I would be exactly what I am now - overly frustrated and with the exactly same amount of time completely lost into studying a bunch of tools only to realize that I should avoid using them at all costs.

I'm sorry if I offend somebody by posting this emotional message, I just try to give you another point of view - don't put restrictions and hide the reasoning. Instead, support the thing that is widespread and advise that in certain conditions there are better things to do. And if it doesn't work for some edge cases, or even for half the cases - place a well elaborated warning. Then if programmers still make the mistake - well, let them learn by it. 'Cause that's the way people learn .. they make mistakes. By preventing them from making the mistake, you actually rob them of learning.

----------
nosy: +vivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 13:50:26 2010
From: report at bugs.python.org (Martin Gfeller Martin Gfeller)
Date: Fri, 17 Dec 2010 12:50:26 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292590226.48.0.942533763811.issue1449496@psf.upfronthosting.co.za>


Martin Gfeller				Martin Gfeller <gfe at comit.ch> added the comment:

Martin, we're running with this for years and with many extensions modules, without an issue. What is 64-bit safe should be 32-bit safe, not only 31-bit safe. But you're right, this is not a proof, and we have switched to 64-bit ourselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Fri Dec 17 13:58:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 12:58:44 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292590724.35.0.836679810329.issue10724@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The source used to create _socket.pyd is in Modules/socketmodule.c in the source code tarball available from the python web site.  As neologix says, it is a thin wrapper around the OS level socket library.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Fri Dec 17 14:06:50 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Dec 2010 13:06:50 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292591210.9.0.678446987623.issue1449496@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> What is 64-bit safe should be 32-bit safe, not only 31-bit safe

Not here. Python uses "signed size_t" for various lengths and sizes.
On win32 this only gives you 31 bits...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Fri Dec 17 14:07:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 13:07:36 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292591256.55.0.0621905639312.issue10726@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not necessarily opposed to this, but an alternative is to modify pyspecific.py so that it generates text output from the ReST when it builds the pydoc topic index.

----------
components: +Demos and Tools
nosy: +georg.brandl, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 14:11:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 13:11:55 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292591515.81.0.0557058809607.issue10725@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The _total_size thing looks like a wildly bad idea to me, since it's so poorly defined (and relying on a couple of special cases).

Also, "currsize" is quite bizarre. Why not simply "size"?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Fri Dec 17 15:18:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 14:18:16 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292595496.94.0.749907868475.issue2736@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Alexander, I agree with Velko in that it isn't obvious to me how the addition of localtime would answer the desire expressed in this issue.  It addresses Antoine's complaint about aware datetimes, but I don't see that it does anything for the "conversion to epoch based timestamp" issue.  That is at the very least a documentation issue, since IMO we should be providing our users with the tools they need to interoperate with the systems they need to interoperate with.

Velko: on the other hand, given Victor's research, I don't see float seconds since an epoch appearing anywhere as a standard.  Where do you see this being used as a standard?  I also don't understand your complaint about the fact that the one-liner creates a timetuple.  datetime stores the date and time information as discrete fields, so generating a timetuple is a natural conversion path.  

Obviously one could avoid the creation of a Python tuple by calling the C mktime directly in the C code, as has been proposed.  I don't see, myself, what would be so bad about providing a 'to_crt_timestamp' method that would, in essence, be the kind of light wrapper around the system API that we provide in so many other places in Python.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 15:28:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 14:28:44 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1292595496.94.0.749907868475.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292596118.3726.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Velko: on the other hand, given Victor's research, I don't see float
> seconds since an epoch appearing anywhere as a standard.

Well, given that we already have fromtimestamp(), this sounds like a
poor argument against a totimestamp() method (or whatever it gets
called).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 15:50:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 14:50:08 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292597408.46.0.282192179759.issue10726@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No need for any of that -- the output you see already is the text output from Sphinx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 15:50:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 14:50:14 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292597414.28.0.0638819692847.issue10726@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:03:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 17 Dec 2010 15:03:15 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1292598195.86.0.775653179542.issue9011@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, sorry;  I'm not likely to find time to do anything with this.  Unassigning, and downgrading priority.

Is it worth leaving this open in case anyone wants to do something about it?

----------
assignee: mark.dickinson -> 
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:15:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 15:15:00 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292598900.79.0.454981142566.issue10726@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, in that case, can we change the text style for code and related markup to be something prettier?  Normal single quotes, perhaps?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:15:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 15:15:15 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292598915.5.0.625751225604.issue10726@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

s/prettier/more readable/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:16:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 15:16:50 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1292599010.93.0.59510812243.issue9011@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Given the long projected lifetime of 2.7, I suppose it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:27:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:27:56 +0000
Subject: =?utf-8?q?=5Bissue10726=5D_pydoc=3A_don=E2=80=99t_display_raw_reST_in_key?=
	=?utf-8?q?word_help?=
In-Reply-To: <1292588244.03.0.247847700331.issue10726@psf.upfronthosting.co.za>
Message-ID: <1292599676.73.0.444476558258.issue10726@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sure, I can do that for the next version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10726>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:36:31 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 17 Dec 2010 15:36:31 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1292600191.66.0.135580963425.issue10155@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

So, do you have any suggestions for a specific change to the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:40:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:40:16 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1292600416.44.0.89884228217.issue8754@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The change would be fine with me.  What happens with the PyUnicode_FromString() usage in the patch if the string cannot be decoded?  That should not lead to a UnicodeError being raised.

Also, the __main__ changes look gratuitous to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:42:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:42:30 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292600550.5.0.170469577694.issue10454@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 -- Didn't read through all of the diff, but in general I trust you enough to believe that the new version is better than the old :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:44:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:44:29 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292600669.76.0.840679877012.issue10723@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Basically fine, but the docs for indentation and tab error should document their inheritance more explicitly.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:47:18 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 17 Dec 2010 15:47:18 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292600838.39.0.711739780819.issue9234@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The patch looks basically okay to me, though this line makes me nervous:

  dest += ' (%s)' % ', '.join(aliases)

Since this is just for help formatting, can't you just modify metavar instead? The dest is the attribute on the namespace where the result should be stored. The metavar is the value that should be displayed in help messages.

As to where the aliases should be printed, I don't have a strong preference. The svn aliases show up when you do a generic "svn help" (but not if you do a "svn help blame") and looks like:

Available subcommands:
   add
   blame (praise, annotate, ann)
   ...

The hg aliases show up when you do a "hg help commit" (but not if you do a "hg help") and looks like:

hg commit [OPTION]... [FILE]...

aliases: ci

I guess the patch makes it pretty easy to emulate the svn version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:49:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:49:42 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292600982.37.0.841280200646.issue9234@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I can see that this is really useful; approved for beta2 as soon as Steven's issue from the last message is handled.

----------
assignee: georg.brandl -> bethard
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:51:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:51:40 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292601100.39.0.53275616686.issue10559@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

"Use that list" doesn't make me happy, what about "access"?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:53:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:53:31 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1292601211.57.0.835796249899.issue10609@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why not replace it with an example that uses get() or setdefault() then?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10609>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:58:03 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 17 Dec 2010 15:58:03 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292601483.99.0.153251138845.issue9938@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

In the short term, just catch the SystemExit.

In the slightly longer term, we could certainly provide a subclass, say, ErrorRaisingArgumentParser, that overrides .exit and .error to do nothing but raise an exception with the message they would have printed. We'd probably have to introduce a new Exception subclass though, maybe ArgumentParserExit or something like that.

Anyway if you're interested in this, please file a new ticket (preferably  with a patch). Regardless of whether we ever provide the subclass, we certainly need to patch the documentation to tell people how to override error and exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:58:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:58:42 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292601522.83.0.699486535813.issue8753@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yep, looks good, please commit.

----------
assignee: docs at python -> eric.araujo
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Fri Dec 17 16:59:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:59:36 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292601576.1.0.192143176714.issue9264@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, it's the new recommended style.  (Please add to documenting/ when convenient :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:06:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:06:25 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292601985.51.0.432693662616.issue10559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Attached diff provides another suggested rewording that I think is clearer.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file20093/tut_argv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:07:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 16:07:29 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602049.42.0.457237393676.issue10559@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:09:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:09:00 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602140.65.0.0165896597336.issue10559@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file20093/tut_argv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:09:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:09:18 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602158.6.0.763924818002.issue10559@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file20094/tut_argv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:12:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:12:22 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602342.3.0.662338989107.issue10559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r87337.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:19:56 2010
From: report at bugs.python.org (Velko Ivanov)
Date: Fri, 17 Dec 2010 16:19:56 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292602796.92.0.849219759588.issue2736@psf.upfronthosting.co.za>


Velko Ivanov <vivanov at ivanov-nest.com> added the comment:

> on the other hand, given Victor's research, I don't see float seconds since an epoch appearing anywhere as a standard.  Where do you see this being used as a standard?

Yes, I didn't mean standard as in RFCed and recommended and dominant, sorry if it sounded that way. I meant just that it is quite common in many places, big and small.

> I also don't understand your complaint about the fact that the one-liner creates a timetuple.  datetime stores the date and time information as discrete fields, so generating a timetuple is a natural conversion path.  

Well, the timetuple is not a tuple, but an object filled with attributes. It contains a few more than are required for this conversion and it doesn't contain one that is required. Therefore I really see that as an inelegant and ineffective way to do the conversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:21:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:21:11 +0000
Subject: [issue8154] os.execlp('true') crashes the interpreter on 2.x
In-Reply-To: <1268741143.77.0.223951034557.issue8154@psf.upfronthosting.co.za>
Message-ID: <1292602871.06.0.770190820907.issue8154@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, this went in to 2.7 without the OS conditional, and there has been no great hue and cry, so I guess it was safe enough :)

As for the difference in error message between execlp and execlpe, I think that's fine.  The execlpe index error message is accurate: execlpe requires an 'env' arg, and it was missing.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8154>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:31:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:31:18 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292603478.12.0.826919725087.issue10454@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r87338.  Backporting the relevant bits will be a bit of a pain, anyone who feels like doing it is welcome to.  I may or may not get to it myself.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:36:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 16:36:31 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292603791.54.0.132315964059.issue8753@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Committed in r87339.  Thanks everyone for the feedback!

----------
assignee: eric.araujo -> stutzbach
keywords:  -needs review
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Fri Dec 17 17:59:28 2010
From: report at bugs.python.org (And Clover)
Date: Fri, 17 Dec 2010 16:59:28 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1292605168.82.0.161814665109.issue10155@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

No, not specifically. My patch is conservative about what variables it recodes, yours more liberal, but it's difficult to say which is the better approach, or what PEP 3333 requires.

If you're happy with the current patch, go ahead, let's have it for 3.2; I don't foresee significant problems with it. It's unlikely anyone is going to be re-using the SSL_ or REDIRECT_ variable names for something other than what Apache uses them for. There might be some confusion from IIS users over what encoding REMOTE_USER should be in, but I can't see any consistent resolution for that issue, and we'll certainly be in a better position than we are now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:06:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 17:06:11 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1292595496.94.0.749907868475.issue2736@psf.upfronthosting.co.za>
Message-ID: <AANLkTikTqMMturzPCaFPZ3Fj7odhSXdFAKPbRH0iLeXE@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, Dec 17, 2010 at 9:18 AM, R. David Murray <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Alexander, I agree with Velko in that it isn't obvious to me how the addition of localtime
> would answer the desire expressed in this issue.

Conversion of UTC datetime to time stamp is trivial:

EPOCH = datetime(1970, 1, 1)
def timestamp(t):
      return (t - EPOCH).total_seconds()

There are several reasons not to include this one-liner in stdlib
(other than it being a one-liner).

1. Different application may need different epoch and retained
precision depends on the choice of the epoch.

2. The code above works only on naive datetime objects assumed to be
in UTC.  Passing say a result of datetime.now() to it is likely to
result in a hard to find bug.

3. While it is not hard to extend the timestamp(t) code to cover aware
datetime objects that use fixed offset tzinfo such as those with
tzinfo set to a datetime.timezone instance, it is not well defined for
the "smart" tzinfo implementations that do automatic DST adjustment.
This is where the localtime (#9527) issue comes into play.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:17:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 17:17:32 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <AANLkTikTqMMturzPCaFPZ3Fj7odhSXdFAKPbRH0iLeXE@mail.gmail.com>
Message-ID: <1292606247.3672.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 1. Different application may need different epoch and retained
> precision depends on the choice of the epoch.

But then why does fromtimestamp() exist?
And returning a (seconds, microseconds) tuple does retain the precision.

> 2. The code above works only on naive datetime objects assumed to be
> in UTC.

So, if the "trivial" code doesn't work, you can't bring it up as an
argument against shipping this functionality, right?

> 3. While it is not hard to extend the timestamp(t) code to cover aware
> datetime objects that use fixed offset tzinfo such as those with
> tzinfo set to a datetime.timezone instance, it is not well defined for
> the "smart" tzinfo implementations that do automatic DST adjustment.

Still, fromtimestamp() exists and apparently fulfills people's
expectations. So why can't the same strategy be used for totimestamp()
as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:24:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 17:24:31 +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: <1292606671.59.0.916897427511.issue4188@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can confirm that the patch fixes the recursion problem if threading._VERBOSE is set to true, but the test Antoine mentioned hangs when the test suite is run.

_VERBOSE is an internal, undocumented facility, so perhaps the priority on this isn't really "high".

On the other hand, Antoine's patch takes things from non-functional to at least partially functional, so perhaps it is worth applying as is, pending someone figuring out where the test hang is coming from.

I looked in to this briefly, but I have no clue how to trigger this in a unit test, since it seems to happen when regrtest imports logging which imports threading, and appears to my threading-ignorant eyes to be tied to conditions that only exist at initial module import.

----------
nosy: +r.david.murray
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4188>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:24:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 17:24:54 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <4D0B2381.7070408@v.loewis.de>
Message-ID: <AANLkTinxRV3mS04pvW6qqi0=2Sho6miTzu9-ibtYNt4E@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Dec 17, 2010 at 3:47 AM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> The worst case (wrt. cskipped) is the maximum number of characters that
> can get combined into a single base character. It used to be (and I
> hope still is) 20 (decomposition of U+FDFA).
>

The C forms (NFC and NFKC) do canonical composition and U+FDFA is a
compatibility composite. (BTW, makeunicodedata.py checks that maximum
decomposed length of a character is < 19, but it would be better if it
would compute and define a named constant, say MAXDLENGTH, to be used
instead of literal 20.)  As far as I (and a two-line script) can tell
the maximum length of a canonical decomposition of a character is 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:37:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 17:37:26 +0000
Subject: [issue10711] Rip out HTTP 0.9 client support
In-Reply-To: <1292432698.78.0.594039389976.issue10711@psf.upfronthosting.co.za>
Message-ID: <1292607446.25.0.00986681697887.issue10711@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r87340.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10711>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:46:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 17:46:09 +0000
Subject: [issue4188] test_threading hang when running as verbose
In-Reply-To: <1224793703.28.0.169476277835.issue4188@psf.upfronthosting.co.za>
Message-ID: <1292607969.43.0.285322825259.issue4188@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I committed the patch in r87341 (3.2), r87342 (3.1) and r87343 (2.7).

----------
priority: high -> normal
stage: patch review -> needs patch
title: Lib/threading.py causes infinite recursion when running as verbose -> test_threading hang when running as verbose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4188>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:47:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Dec 2010 17:47:23 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292608043.1.0.964921182453.issue10725@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Updated to use ABCs but still relies on user objects implementing __sizeof__.  So it is accurate whenever sys.getsizeof() is accurate.

----------
Added file: http://bugs.python.org/file20095/sized_cache2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:49:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 17:49:44 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1292606247.3672.6.camel@localhost.localdomain>
Message-ID: <AANLkTik0bPmPj7JOTGJstMhZpAr4wmy4TbbgLMo4AsEV@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> 1. Different application may need different epoch and retained
>> precision depends on the choice of the epoch.
>
> But then why does fromtimestamp() exist?

A better question is why datetime.utcfromtimestamp(s) exists given
that it is actually longer than equivalent EPOCH + timedelta(0, s)?  I
am not responsible for either of these methods, but at least
datetime.fromtimestamp(s, tz) is well defined for any timezone and
timestamp unlike its inverse.

> And returning a (seconds, microseconds) tuple does retain the precision.
>

It does, but it does not help much those who want a float - they would
still need another line of code.  Note that with divmod(timedelta,
timedelta), you can now easily extract   (seconds, microseconds)  or
any other tuple like (weeks, days, seconds. microseconds) from
timedelta objects.  See msg75904 above.

>> 2. The code above works only on naive datetime objects assumed to be
>> in UTC.
>
> So, if the "trivial" code doesn't work, you can't bring it up as an
> argument against shipping this functionality, right?
>

Well, no one has come up with the code that does work so far.  Note
that timetuple path does not work either because it does not fill
tm_isdst correctly.  The only solution I can think of for having
proper inverse to fromtimestamp() is to add isdst to datetime objects.
 This would allow correct round-tripping between datetime and
timetuple and datetime and timestamp.

>> 3. While it is not hard to extend the timestamp(t) code to cover aware
>> datetime objects that use fixed offset tzinfo such as those with
>> tzinfo set to a datetime.timezone instance, it is not well defined for
>> the "smart" tzinfo implementations that do automatic DST adjustment.
>
> Still, fromtimestamp() exists and apparently fulfills people's
> expectations. So why can't the same strategy be used for totimestamp()
> as well?

Because in certain timezones fromtimestamp() can return the same
datetime value for different timestamps and some datetime values do
not have a corresponding timestamp.  I have not seen a working
proposal on how to handle these issues yet.  You are asking to provide
an inverse to an existing function simply because the function exists.
 But the function in question is not invertible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:54:59 2010
From: report at bugs.python.org (Mads Michelsen)
Date: Fri, 17 Dec 2010 17:54:59 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292608499.77.0.406794232856.issue10680@psf.upfronthosting.co.za>


Mads Michelsen <madchine at gmail.com> added the comment:

@eric.araujo: What you're saying is 'if you want it done, do it yourself'? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Fri Dec 17 18:57:21 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 17:57:21 +0000
Subject: [issue2226] Small _abcoll Bugs / Oddities
In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za>
Message-ID: <1292608641.26.0.46867312161.issue2226@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Raymond,

Do you have around 10 minutes today to look at the patch I submitted in Issue 8743?  It appears to solve both this issue and that one, which have priorities critical and high, respectively.

It's a reasonably small patch: around 20 lines changed plus 20 lines added, all Python code.  Here's a direct link:

http://bugs.python.org/file20045/set-with-Set.patch

If it looks good to you, I'd like to commit it in time for 3.2b2 so that it gets as much exercise as possible before 3.2-final.

Earlier you had expressed that adding the __rand__ methods to collections.Set would be tricky issue, so I'm concerned that I have overlooked something important and obvious.

(Feedback from others is, of course, welcome as well)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2226>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:01:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Dec 2010 18:01:01 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1292608861.36.0.136597781629.issue6075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thank you very much for the patch. I have updated it and modified it somewhat to work with the latest tip for py3k (3.2b1), 3.1.3+, and 2.7.1+ and to work with both AquaTk Cocoa 8.5 and preserve current behavior with legacy AquaTk Carbon 8.4.

Since there are no automated tests for IDLE in the standard library and since the issues here had to do with differences in menu cascades and options, I created a program to introspect IDLE menus using the OS X GUI Scripting interface via py-appscript.  That allowed me to semi-automatically capture the menu configurations for the IDLE configurations of interest (in particular, Apple-supplied Tk vs ActiveState Tk).  The following Tcl/Tk configurations - all currently, or shortly to be, supported by python.org installers - were tested:

OS X          Tcl/Tk
====          ======
10.6  64-bit  ActSt 8.5.9 Cocoa
10.6  64-bit  Apple 8.5.7 Cocoa
10.6  32-bit  ActSt 8.4.19 Carbon
10.6  32-bit  Apple 8.4.19 Carbon
10.5  32-bit  ActSt 8.4.19 Carbon
10.5  32-bit  Apple 8.4.7 Carbon
10.4  32-bit  ActSt 8.4.19 Carbon
10.4  32-bit  Apple 8.4.7 Carbon
10.3  32-bit  ActSt 8.4.19 Carbon

Each of those Tcl/Tk configurations was tested with both IDLE.app and bin/idle, each with both py3k(3.2b1+) and 2.7.1+ builds, and each of those with both IDLE Editor windows and IDLE shell windows (they have somewhat different menu configurations).  Note that testing on 10.3 was much more limited since appscript, and hence the menutester, is not supported there.  Also no regressions were noted when applied to 3.1.3+ in a 32-bit only build.

So far, the recently available ActiveState 64-bit Cocoa Tcl/Tk 8.5 has proven to be much more stable than the Apple-supplied 8.5 version in 10.6, which had rendered the 64-bit versions of IDLE virtually unusable up to now.  With the final patches applied, I found no regressions in the menu cascades for IDLE.app.  When running bin/idle (from the command line), there is a slight difference when using Cocoa Tk vs Carbon Tk.  Both variants of AquaTk automatically supplies the application names from the app bundle plist. Because of the way bin/idle is structured today, the app name appears as "Python" rather than "IDLE".  With Cocoa Tk, that appears in a couple more menu items ("About app" and "app Help") than it already does with Carbon Tk.  While that would be nice to fix at some point, it is an existing cosmetic issue and  I assume most inexperienced users will use IDLE.app, where there is no discrepancy.

I believe this fix is ready to be applied and should go into 3.2 (and as soon as possible released for 2.7) in conjunction with building the 64-bit OS X installer to allow use of the ActiveState Cocoa 8.5.  This will fix a number of reported problems with the broken IDLE with previous 64-bit OS X installers.  Still to be done prior to release is updating the installer README and documenting a few minor issues.  A longer-term issue is to make the menu introspection tests automatic enough to be added to the standard tests as an optional OS X test.

----------
assignee: ned.deily -> ronaldoussoren
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
stage:  -> patch review
Added file: http://bugs.python.org/file20096/issue6075_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:01:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Dec 2010 18:01:29 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1292608889.38.0.941143130294.issue6075@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file20097/issue6075_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:02:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Dec 2010 18:02:17 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292608937.06.0.394550080263.issue10725@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Another thing to work out:  not double counting duplicate objects: 
 
   [1000, 2000, 3000] is bigger than [None, None, None]

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:06:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 18:06:55 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292608043.1.0.964921182453.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292609211.3672.38.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Updated to use ABCs but still relies on user objects implementing
> __sizeof__.  So it is accurate whenever sys.getsizeof() is accurate.

I'm really -1 on this. It's better to give no measurement than to give a
totally wrong indication. The fact that you had to special-case
containers shows that getsizeof() is *not* the right solution for this.

(because if it was, you could rely on the containers' __sizeof__ instead
of overriding it)

The "size of an object and its contents" generally doesn't make any
sense, because the object graph is massively connected. getsizeof()
gives you the basic internal footprint of the object, but that's all.
It's really not a high-level tool for the everyday programmer, and
relying on it to say how much memory would be saved by getting rid of
certain objects is bogus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:09:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Dec 2010 18:09:12 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1292609352.33.0.651008883229.issue9907@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe this fix should go into 3.2 (and 2.7) as it has been reported by a number of people in various places and the fix risk is low.

----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:13:04 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Dec 2010 18:13:04 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1292609584.83.0.494982436317.issue10404@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I think this should be applied for 3.2 (and 2.7 and 3.1). The risk is low and the benefit to OS X IDLE users is great, since without it there is no way to use IDLE's breakpoint facility.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:17:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 18:17:50 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <AANLkTik0bPmPj7JOTGJstMhZpAr4wmy4TbbgLMo4AsEV@mail.gmail.com>
Message-ID: <1292609857.3672.49.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >> 1. Different application may need different epoch and retained
> >> precision depends on the choice of the epoch.
> >
> > But then why does fromtimestamp() exist?
> 
> A better question is why datetime.utcfromtimestamp(s) exists given
> that it is actually longer than equivalent EPOCH + timedelta(0, s)?

??? EPOCH is not even a constant in the datetime module.

And regardless, the point is *not* the number of characters typed, but
how easy it is to come up with the solution. Calling the appropriate
(and appropriately-named) method is much easier than coming up with the
right datetime arithmetic incantation. It's Python, not Perl. "There
should be one obvious way to do it".

> > And returning a (seconds, microseconds) tuple does retain the precision.
> >
> 
> It does, but it does not help much those who want a float - they would
> still need another line of code.

Yes, but a very obvious one at least.

> Note that with divmod(timedelta,
> timedelta), you can now easily extract   (seconds, microseconds)  or
> any other tuple like (weeks, days, seconds. microseconds) from
> timedelta objects.

Do you think many users even think of calling divmod() timedelta
objects? I don't, personally.

You apparently hold the opinion that the datetime module should be
reserved for experts in arithmetic over dates, times and timedeltas. But
it's not. It's the Python stdlib and it should provide reasonably
high-level tools to do the job.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:18:53 2010
From: report at bugs.python.org (T Rink)
Date: Fri, 17 Dec 2010 18:18:53 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292549123.48.0.834556423019.issue10722@psf.upfronthosting.co.za>
Message-ID: <AANLkTimfv73isz9VgjyhE1rbUT4y+DMQZmVymBe2sU9w@mail.gmail.com>


T Rink <tr03 at jm.rinkleff.com> added the comment:

Thanks for your comments.

I also expect the problem is the interation of Python with Windows, but
whether they fault lies by Python or Windows I cannot say.

I can say that the problem seems to come and go away.  Last night it did not
work. This morning it did. A few minutes ago it did.  Now it does not.

 I have to my knowledge a standard installation.  Checking Google, which is
where I started in looking for a solution, shows that the error message has
occured for other people as well.

Again any suggestions are appreciated.

Thanks.

On Fri, Dec 17, 2010 at 2:25 AM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Perhaps Terry will have some advice (I've added him as nosy), but you may
> have better luck asking on the python mailing list (see mail.python.orgfor list of lists) or its linked newsgroup comp.lang.python, or on the
> #python irc channel (though they may tell you to dump Idle, depending on who
> is in channel at the time :)
>
> It is not likely that what you are experiencing is an actual bug in Ptyhon,
> since Idle on windows works for lots of people.  However understanding your
> problem and its solution might help us make the Idle experience more
> friendly, so I'll leave it to Terry to decide how he wants to handle this.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10722>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20098/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________
-------------- next part --------------
Thanks for your comments.<br><br>I also expect the problem is the interation of Python with Windows, but whether they fault lies by Python or Windows I cannot say. <br><br>I can say that the problem seems to come and go away.?? Last night it did not work. This morning it did. A few minutes ago it did.?? Now it does not. ?? <br>
<br>??I have to my knowledge a standard installation.?? Checking Google, which is where I started in looking for a solution, shows that the error message has occured for other people as well.<br><br>Again any suggestions are appreciated. <br>
<br>Thanks.?? <br><br><div class="gmail_quote">On Fri, Dec 17, 2010 at 2:25 AM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
Perhaps Terry will have some advice (I&#39;ve added him as nosy), but you may have better luck asking on the python mailing list (see <a href="http://mail.python.org" target="_blank">mail.python.org</a> for list of lists) or its linked newsgroup comp.lang.python, or on the #python irc channel (though they may tell you to dump Idle, depending on who is in channel at the time :)<br>

<br>
It is not likely that what you are experiencing is an actual bug in Ptyhon, since Idle on windows works for lots of people. ??However understanding your problem and its solution might help us make the Idle experience more friendly, so I&#39;ll leave it to Terry to decide how he wants to handle this.<br>

<br>
----------<br>
nosy: +r.david.murray<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/issue10722" target="_blank">http://bugs.python.org/issue10722</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Dec 17 19:19:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 18:19:00 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292609940.08.0.520097097763.issue6791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now that 0.9 client support has been removed, this can proceed (at least for 3.2).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Fri Dec 17 19:57:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 18:57:18 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1292609857.3672.49.camel@localhost.localdomain>
Message-ID: <AANLkTik8xGNzvgCR=xMb96QQF9Vb-ik-0FyGptNvw95r@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> A better question is why datetime.utcfromtimestamp(s) exists given
>> that it is actually longer than equivalent EPOCH + timedelta(0, s)?
>
> ??? EPOCH is not even a constant in the datetime module.
>
No, and it does not belong there.  A higher level library that uses
seconds since epoch for interchange may define it (and make a decision
whether it should be a naive datetime(1970, 1, 1) or datetime(1970, 1,
1, tzinfo=timezone.utc)).

> And regardless, the point is *not* the number of characters typed, but
> how easy it is to come up with the solution. Calling the appropriate
> (and appropriately-named) method is much easier than coming up with the
> right datetime arithmetic incantation. It's Python, not Perl. "There
> should be one obvious way to do it".
>

I don't see anything obvious about the choice between
utcfromtimestamp(s), fromtimestamp(s) and utcfromtimestamp(s,
timezone.utc).

datetime(1970, 1, 1) + timedelta(seconds=s)

is obvious, self-contained,  short and does not require any knowledge
other than elementary school arithmetic to understand.  Compared to
this, "utcfromtimestamp" is a monstrosity that suggests that something
non-trivial, such as UTC leap seconds is been taken care of.

>> > And returning a (seconds, microseconds) tuple does retain the precision.
>> >
>>
>> It does, but it does not help much those who want a float - they would
>> still need another line of code.
>
> Yes, but a very obvious one at least.
>

Let's see:

def floattimestamp(t):
      s, us = t.totimestamp()
      return s + us * 1e-6

and

def floattimestamp(t):
      s, us = t.totimestamp()
      return s + us / 1000000

which one is *obviously* correct?  Are they *obviously* equivalent?

Note that when timedelta.total_seconds() was first committed, it
contained a numerical bug.  See issue8644.

>> Note that with divmod(timedelta,
>> timedelta), you can now easily extract ? (seconds, microseconds) ?or
>> any other tuple like (weeks, days, seconds. microseconds) from
>> timedelta objects.
>
> Do you think many users even think of calling divmod() timedelta
> objects? I don't, personally.
>
> You apparently hold the opinion that the datetime module should be
> reserved for experts in arithmetic over dates, times and timedeltas. But
> it's not. It's the Python stdlib and it should provide reasonably
> high-level tools to do the job.
>

Sure, but if the goal is to implement json serialization of datetime
objects, maybe stdlib should provide a high-level tool for *that* job?
  Using float representation of datetime is probably the worst option
for json: it is non-standard, may either loose information or
introduce spurious differences, and is not human-readable.

In any case, you ignore the hard question about totimestamp():
fromtimestamp() is not invertible in most real life timezones.  If you
have a solution that does not restrict totimestamp() to UTC, I would
like to hear it.  Otherwise, I don't see any problem with (t -
datetime(1970, 1, 1)).total_seconds() expression.  Maybe we can add
this recipe to utcfromtimestamp() documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:01:39 2010
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 17 Dec 2010 19:01:39 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292612499.94.0.987138304043.issue2736@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
nosy:  -tebeka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:08:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 17 Dec 2010 19:08:11 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <AANLkTinxRV3mS04pvW6qqi0=2Sho6miTzu9-ibtYNt4E@mail.gmail.com>
Message-ID: <4D0BB515.6090602@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The C forms (NFC and NFKC) do canonical composition and U+FDFA is a
> compatibility composite. (BTW, makeunicodedata.py checks that maximum
> decomposed length of a character is < 19, but it would be better if it
> would compute and define a named constant, say MAXDLENGTH, to be used
> instead of literal 20.)  As far as I (and a two-line script) can tell
> the maximum length of a canonical decomposition of a character is 4.

Even better - so allowing for 20 characters should be safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:11:11 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 19:11:11 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292613071.86.0.0172362038006.issue10723@psf.upfronthosting.co.za>


flashk <flashk at gmail.com> added the comment:

I just attached a new patch that explicitly mentions the inheritance of IndentationError and TabError.

----------
Added file: http://bugs.python.org/file20099/exceptions_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:17:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 19:17:48 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <4D0BB515.6090602@v.loewis.de>
Message-ID: <AANLkTimX6RhopEjnnjooWQg_QQsGffHfW8gLJaN3A192@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Dec 17, 2010 at 2:08 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
>>?As far as I (and a two-line script) can tell
>> the maximum length of a canonical decomposition of a character is 4.
>
> Even better - so allowing for 20 characters should be safe.

I don't disagree, but the number of "break" and "continue" statements
before cskipped++ makes me nervous.  This said, I am going to  add
test cases from the first post to test_unicodedata (I think it is a
better place than test_normalise because the latter is skipped by
default) and commit.

Improving the algorithm is a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:35:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 19:35:44 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <AANLkTik8xGNzvgCR=xMb96QQF9Vb-ik-0FyGptNvw95r@mail.gmail.com>
Message-ID: <1292614540.3672.82.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > ??? EPOCH is not even a constant in the datetime module.
> >
> No, and it does not belong there.

And so what was your point exactly?

> A higher level library that uses
> seconds since epoch for interchange

I don't think the "time" module can be named "higher level", and it
still handles such timestamps.

> datetime(1970, 1, 1) + timedelta(seconds=s)
> 
> is obvious, self-contained,  short and does not require any knowledge
> other than elementary school arithmetic to understand.

Sigh.
Again: it's so obvious that you're the only one who seems to easily come
up with those solutions. How many times does it have to be repeated?

> Compared to
> this, "utcfromtimestamp" is a monstrosity that suggests that something
> non-trivial, such as UTC leap seconds is been taken care of.

I don't see anything suggesting it is a monstrosity. The name is
grammatically bizarre, but that's all.

> Let's see:
> [snip]
>
> which one is *obviously* correct?  Are they *obviously* equivalent?

Both are obviously correct for whatever the non-perverted user has in
mind. People in real life don't care whether they will retain
microsecond precision when carrying a floating point timestamp around.
For the simple reason that the data source itself will not have such
precision.

> Note that when timedelta.total_seconds() was first committed, it
> contained a numerical bug.  See issue8644.

So? What is your point?

> In any case, you ignore the hard question about totimestamp():
> fromtimestamp() is not invertible in most real life timezones.  If you
> have a solution that does not restrict totimestamp() to UTC, I would
> like to hear it.

IMO, the solution would have the datetime object carry the offset from
UTC with it, rather than try to be smart and compute it dynamically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:39:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Dec 2010 19:39:28 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292614768.22.0.244362703631.issue10725@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20095/sized_cache2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Fri Dec 17 20:41:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 19:41:31 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292614891.62.0.403419572198.issue6791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch limiting line length everywhere in http.client, + tests (it also affects http.server since the header parsing routine is shared).

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20100/httplinelength.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Fri Dec 17 21:05:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 20:05:29 +0000
Subject: [issue10727] intermittent test_cmd_line failure
In-Reply-To: <1292616329.6.0.61377155391.issue10727@psf.upfronthosting.co.za>
Message-ID: <1292616329.6.0.61377155391.issue10727@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It really looks like a subprocess issue:

======================================================================
ERROR: test_usage (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py", line 43, in test_usage
    rc, out, err = assert_python_ok('-h')
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 50, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 30, in _assert_python
    env=env)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", line 721, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor


See http://www.python.org/dev/buildbot/all/builders/PPC%20Tiger%203.x/builds/1213/steps/test/logs/stdio

----------
assignee: gregory.p.smith
components: Library (Lib)
messages: 124254
nosy: gregory.p.smith, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: intermittent test_cmd_line failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10727>
_______________________________________

From report at bugs.python.org  Fri Dec 17 21:07:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 20:07:00 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1292614540.3672.82.camel@localhost.localdomain>
Message-ID: <AANLkTimUuUT-_q7drEeOMuAHqk6Xq3AZG_-=gHS-kFc6@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> I don't think the "time" module can be named "higher level", and it
> still handles such timestamps.
>
>> datetime(1970, 1, 1) + timedelta(seconds=s)
>>
>> is obvious, self-contained, ?short and does not require any knowledge
>> other than elementary school arithmetic to understand.
>
> Sigh.
> Again: it's so obvious that you're the only one who seems to easily come
> up with those solutions. How many times does it have to be repeated?
>

Remember, most of the code is written once, but read and edited many
times.  Show me one person who will have trouble understanding what
datetime(1970, 1, 1) + timedelta(seconds=s) means and show me another
who can understand datetime.utcfromtimestamp(s) without reading the
manual.

>> Compared to
>> this, "utcfromtimestamp" is a monstrosity that suggests that something
>> non-trivial, such as UTC leap seconds is been taken care of.
>
> I don't see anything suggesting it is a monstrosity. The name is
> grammatically bizarre, but that's all.
>

Yes, UTC not being a proper acronym in any human language is one
problem, Python datetime not being able to represent some valid UTC
times is another.

That's correct, but most users expect their timestamps to be the same
when saved on one system and read on another.  Granted, most users
expect the same from their floats as well, but this can only be solved
by education.   Calendaric calculations are complex enough that we
don't want to expose users to floating point gotchas at the same time.

>> Note that when timedelta.total_seconds() was first committed, it
>> contained a numerical bug. ?See issue8644.
>
> So? What is your point?
>

I thought the point was obvious: conversion between time values and
float is non-trivial and error prone.  Users should not be encouraged
to casually convert (seconds, microseconds) tuples to floats.  If they
do, chances are they will do it differently in different parts of the
program.

>> In any case, you ignore the hard question about totimestamp():
>> fromtimestamp() is not invertible in most real life timezones. ?If you
>> have a solution that does not restrict totimestamp() to UTC, I would
>> like to hear it.
>
> IMO, the solution would have the datetime object carry the offset from
> UTC with it, rather than try to be smart and compute it dynamically.
>

Ditto.  This is exactly what issue9527 is attempting to achieve.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 21:24:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 20:24:43 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292617483.34.0.575176298575.issue2736@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy:  -Alexander.Belopolsky
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 21:26:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 20:26:45 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <AANLkTimUuUT-_q7drEeOMuAHqk6Xq3AZG_-=gHS-kFc6@mail.gmail.com>
Message-ID: <1292617600.3672.85.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yes, UTC not being a proper acronym in any human language is one
> problem,

Ok. Too bad you don't live on the same planet than most of us. I bail
out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 21:54:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 17 Dec 2010 20:54:57 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1292617600.3672.85.camel@localhost.localdomain>
Message-ID: <AANLkTimZbuqQnTEhxMCKsDDQ1hA35kG8hJXU8nKD64E3@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Dec 17, 2010 at 3:26 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>
>> Yes, UTC not being a proper acronym in any human language is one
>> problem,
>
> Ok. Too bad you don't live on the same planet than most of us. I bail
> out.

Sorry that my attempt at humor has proven to be too subtle.  I was
referring to the following fact:

"""
The International Telecommunication Union wanted Coordinated Universal
Time to have the same symbol in all languages. English and French
speakers wanted the initials of both their respective language's terms
to be used internationally: "CUT" for "coordinated universal time" and
"TUC" for "temps universel coordonn?". This resulted in the final
compromise of "UTC".
"""

http://en.wikipedia.org/wiki/Coordinated_Universal_Time

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 22:29:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 21:29:34 +0000
Subject: [issue2690] Precompute range length and enhance range subscript
	support
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1292621374.79.0.43524847565.issue2690@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Doc change committed to py3k in r87346.  Thanks, SilentGhost!

I also committed r87349 to reverse r87162 (which was in the wrong branch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Fri Dec 17 22:43:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Dec 2010 21:43:55 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1292622235.91.0.937616349668.issue2736@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like it's not possible to choose between float and (int, int) output type for datetime.totimestamp(). One is more practical (and enough for people who doesn't need an exact result), and one is needed to keep the same resolution than the datetime object. I think that we can add two methods:
 * datetime.totimestamp()->float
 * datetime.totimestamptuple()->(int,int)

I choosed the shortest name for float because I suppose that most users prefer float than a tuple, and so the API is symmetrical:
 * datetime.fromtimestamp(float)->datetime
 * datetime.totimestamp()->float

My patch have to be updated to use the timezone (and the DST thing?) and also to update the Python implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

From report at bugs.python.org  Fri Dec 17 23:17:57 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Dec 2010 22:17:57 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292624277.35.0.972825094934.issue8753@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Err... in r87339 there is a typo in all occurrences of 'Py_ReprEntr': Py_ReprEnter of course!

----------
nosy: +amaury.forgeotdarc
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Fri Dec 17 23:29:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 22:29:22 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292624962.77.0.0725985928959.issue8753@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

On Fri, Dec 17, 2010 at 2:17 PM, Amaury Forgeot d'Arc wrote wrote:
> Err... in r87339 there is a typo in all occurrences of
> 'Py_ReprEntr': Py_ReprEnter of course!

Well, that's embarrassing.  Fixed in r87354.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Fri Dec 17 23:31:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 22:31:27 +0000
Subject: [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292625087.38.0.363211167358.issue8753@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8753>
_______________________________________

From report at bugs.python.org  Fri Dec 17 23:56:30 2010
From: report at bugs.python.org (Jason Scheirer)
Date: Fri, 17 Dec 2010 22:56:30 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292626590.62.0.611321018155.issue1449496@psf.upfronthosting.co.za>


Jason Scheirer <jason.scheirer at gmail.com> added the comment:

I would like to see this reopened: we have a very large class of users that are not ready to entirely port to 64-bit and need this now.

When running a Python script from within a desktop application (which embeds Python and has /LARGEADDRESSAWARE set) or outside in Python.exe (which does not) results in the outputs from the tools calling out to these 32 bit libraries to produce different outputs because the amount of data they are able to allocate and process at the same time. The same Python script that gives correct output on a large dataset in this desktop app will not yield the same quality of results when run overnight as a stand-alone Python script. Essentially this discounts Python scripts as an option for automation in this case.

I understand that yes, applications still cannot allocate more CONTIGUOUS memory, but this is not a regression if it continues to be so. Allowing the process to allocate more TOTAL memory is a net benefit, especially on on complex software systems that can't simply be rebuilt in 64 bit mode due to third-party restraints (tied to a specific library version, lack of access to source, lengthy software approvals processes, etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Sat Dec 18 00:13:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 23:13:51 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1292627631.13.0.291637343045.issue1449496@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When running a Python script from within a desktop application (which
> embeds Python and has /LARGEADDRESSAWARE set) [...]. Essentially this
> discounts Python scripts as an option for automation in this case.

Well, if you already embed Python in your application, you can probably also embed it in a simple console application which will enable automation, can't you?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Sat Dec 18 00:29:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Dec 2010 23:29:03 +0000
Subject: [issue10685] trace does not ignore --ignore-module
In-Reply-To: <1292157270.73.0.200325030661.issue10685@psf.upfronthosting.co.za>
Message-ID: <1292628543.42.0.272885654718.issue10685@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please try the recent 2.7.1 release. This needs to be tested with current 3.1.3 or 3.1.b+ also.

----------
nosy: +eli.bendersky, terry.reedy
title: trace does nto ignore --ignore-module -> trace does not ignore --ignore-module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10685>
_______________________________________

From report at bugs.python.org  Sat Dec 18 00:31:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Dec 2010 23:31:46 +0000
Subject: [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292628706.38.0.528967216193.issue10702@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10702>
_______________________________________

From report at bugs.python.org  Sat Dec 18 00:43:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Dec 2010 23:43:43 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292629423.02.0.915477658527.issue10723@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file20084/exceptions.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Sat Dec 18 01:25:46 2010
From: report at bugs.python.org (Adrian Sampson)
Date: Sat, 18 Dec 2010 00:25:46 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292631946.76.0.939196951566.issue9234@psf.upfronthosting.co.za>


Adrian Sampson <asampson at cs.washington.edu> added the comment:

Thanks for the suggestion, Steven. I hadn't yet internalized the difference between dest and metavar.

This version of the patch modifies metavar instead. Because it looks like this issue is up for 3.2b2, I've modified NEWS and ACKS (I hope this was the right thing to do).

I also see the logic behind both help styles Steven depicts. If there's any interest, I can implement the other (hg) style or make it an option.

----------
Added file: http://bugs.python.org/file20101/argparse-aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Sat Dec 18 01:54:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Dec 2010 00:54:11 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292633651.94.0.879474934778.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 9 of my patch:
 - Create PYTHONNOHANDLER environment variable: don't install the signal handler if the variable is set
 - Rename "Segfault" by "FaultHandler"
 - reverse_string() does nothing if len==0, even if it cannot occur when it's called by dump_decimal() and dump_hexadecimal().
 - _Py_DumpBacktrace() only writes the first 100 frames (arbitrary limit) to avoid unlimited loops

I don't know 100 frames is a good limit or not. Is it enough?

Summary of the patch:
 - Add a fault handler for SIGSEGV, SIGFPE, SIGBUS and SIGILL signals: display the Python backtrace and abort the process (call the debugger on Windows)
 - Add PYTHONNOHANDLER environment variable to disable the fault handler
 - The fault handler is implemented using only very simple instructions: it calls only signal-safe functions and it doesn't allocate memory (on the heap, only some bytes on the stack)
 - The fault handler uses an alternate stack to be able to display the backtrace (to be able to allocate memory on the stack and call functions)

The fault handler has no more the infinite loop issue (because the backtrace is truncated on frame loop).

----------
Added file: http://bugs.python.org/file20102/segfault_handler-9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 01:54:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Dec 2010 00:54:27 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292633667.11.0.241264142945.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19214/segfault_handler-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 01:54:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Dec 2010 00:54:30 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292633670.66.0.223081242614.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19227/segfault_handler-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 01:55:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Dec 2010 00:55:03 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292633703.54.0.757369114783.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19288/segfault_handler-7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 01:55:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Dec 2010 00:55:07 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292633707.68.0.0939949270309.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19289/segfault_handler-8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 02:11:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 18 Dec 2010 01:11:47 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292634707.91.0.939684623228.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I'm tired...

> Summary of the patch:
> - ...abort the process (call the debugger on Windows)

(the debugger is only called if Python is compiled in debug mode)

> - Add PYTHONNOHANDLER environment variable ...

Oops, the correct name is PYTHONNOFAULTHANDLER (no fault handler).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 02:20:11 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 18 Dec 2010 01:20:11 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292635211.68.0.903461046919.issue8863@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Why was sys.setsegfaultenabled() omitted?
It may be useful to disable the handler from a script

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sat Dec 18 03:18:47 2010
From: report at bugs.python.org (Greg Ward)
Date: Sat, 18 Dec 2010 02:18:47 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1292638727.5.0.885460633221.issue6454@psf.upfronthosting.co.za>


Greg Ward <greg at gerg.ca> added the comment:

> I understood Greg?s reply to mean that there was no need for an examples 
> keyword if simple paragraph splitting was added.

Right, but optparse has been superseded by argparse.  So my opinion is even less important than it was before 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Sat Dec 18 03:53:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 18 Dec 2010 02:53:02 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
In-Reply-To: <1292626590.62.0.611321018155.issue1449496@psf.upfronthosting.co.za>
Message-ID: <4D0C220A.8090906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would like to see this reopened: we have a very large class of
> users that are not ready to entirely port to 64-bit and need this
> now.

And I remain -1 to such requests. You can appeal to that by writing a
PEP, or finding a committer who is willing to make this change.

Alternatively, just provide these users with binaries that you built
yourself, or hire somebody to build such binaries for you.

> I understand that yes, applications still cannot allocate more
> CONTIGUOUS memory, but this is not a regression if it continues to be
> so. 

It would be a regression if Python started crashing because of that
change, which is my concern.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Sat Dec 18 04:10:56 2010
From: report at bugs.python.org (Silvio Ricardo Cordeiro)
Date: Sat, 18 Dec 2010 03:10:56 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>


New submission from Silvio Ricardo Cordeiro <silvioricardoc at gmail.com>:

The documentation at http://docs.python.org/dev/library/argparse.html explicitly says that "If file is None, sys.stderr is assumed".

However, both print_usage and print_help assume sys.stdout when file=None. The helper method _print_message actually does it right, when called with file=None.

----------
components: Library (Lib)
messages: 124271
nosy: silvioricardoc
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser.print_help uses sys.stdout
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Sat Dec 18 04:52:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 03:52:30 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1292644350.78.0.176701692607.issue9907@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in 87356 and 2.7 in r87358.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Sat Dec 18 05:09:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 04:09:27 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292645367.34.0.807495842474.issue10728@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think this is a documentation bug, since IMO help should print on stdout, not stderr[1].  I would expect print_usage to do likewise, but for the error to tell print_usage to write to stderr when it calls it...which is exactly what the code does.

[1] I know some unix commands print help to stderr, and this really annoys me when I pipe long help output to less....and it *still* scrolls off the screen.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +bethard, docs at python, r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Sat Dec 18 05:09:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 04:09:55 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292645395.93.0.912821002997.issue10728@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Sat Dec 18 05:24:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Dec 2010 04:24:13 +0000
Subject: [issue10659] Hook scripts for immediate doc build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1292646253.19.0.770082788295.issue10659@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/issue10659>
_______________________________________

From report at bugs.python.org  Sat Dec 18 07:11:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Dec 2010 06:11:39 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292652699.49.0.598818711003.issue10725@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed, getsizeof() on containers only gives the amount of memory consumed by the container itself (this can be difficult to figure out externally for potentially sparse containers like dicts), but leaves the question of the size of the referenced objects open.

Exposing the result of sys.getsizeof() on the cache may not be a bad idea, but the question would be which use cases are handled by that additional information which aren't adequately covered by the simple count of the cache entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Sat Dec 18 08:04:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Dec 2010 07:04:54 +0000
Subject: [issue10725] Better cache instrumentation
In-Reply-To: <1292579314.55.0.548643170883.issue10725@psf.upfronthosting.co.za>
Message-ID: <1292655894.11.0.834838369915.issue10725@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Closed due to lack of interest.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10725>
_______________________________________

From report at bugs.python.org  Sat Dec 18 09:49:32 2010
From: report at bugs.python.org (Ayman Elmasry)
Date: Sat, 18 Dec 2010 08:49:32 +0000
Subject: [issue10729] fwbackups python lib error
In-Reply-To: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>
Message-ID: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>


New submission from Ayman Elmasry <elmasry.ayman at gmail.com>:

I hope this topic is not completely unfitting here.

fwbackups error after backup attempt which concerned python lib:

ERROR : Traceback (most recent call last):   File "/usr/lib/python2.4/site-packages/fwbackups/operations/backup.py", line 698, in start  pkgListfiles = self.createPkgLists()   File "/usr/lib/python2.4/site-packages/fwbackups/operations/backup.py", line 85, in createPkgLists   fh = tempfile.NamedTemporaryFile(suffix='.txt', prefix="%s - tmp" % _('rpm - Package list'), delete=False)  TypeError: NamedTemporaryFile() got an unexpected keyword argument 'delete'

----------
components: Library (Lib)
messages: 124276
nosy: elmasry-ayman
priority: normal
severity: normal
status: open
title: fwbackups python lib error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10729>
_______________________________________

From report at bugs.python.org  Sat Dec 18 09:52:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Dec 2010 08:52:50 +0000
Subject: [issue9775] Multiprocessing, logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1292662370.83.0.0348639445576.issue9775@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not reproducable anymore.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9775>
_______________________________________

From report at bugs.python.org  Sat Dec 18 11:39:32 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 18 Dec 2010 10:39:32 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292668772.21.0.457321176067.issue9234@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Sat Dec 18 11:41:39 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 18 Dec 2010 10:41:39 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292668899.62.0.786345837879.issue10728@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yep, this is a documentation bug. Help is definitely intended to print to stdout.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Sat Dec 18 11:43:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Dec 2010 10:43:14 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292668994.69.0.921012555465.issue9234@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Steven, can you go ahead and apply this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Sat Dec 18 12:26:27 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 18 Dec 2010 11:26:27 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1292671587.38.0.731627513853.issue9234@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Applied in r87362.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Sat Dec 18 14:13:14 2010
From: report at bugs.python.org (Grygoriy Fuchedzhy)
Date: Sat, 18 Dec 2010 13:13:14 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>


New submission from Grygoriy Fuchedzhy <grygoriy.fuchedzhy at gmail.com>:

Please add '.svgz': '.svg.gz' map to mimetypes.suffix_map

----------
components: Library (Lib)
messages: 124282
nosy: gry
priority: normal
severity: normal
status: open
title: add .svgz to mimetypes.suffix_map
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sat Dec 18 14:25:42 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 18 Dec 2010 13:25:42 +0000
Subject: [issue10729] fwbackups python lib error
In-Reply-To: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>
Message-ID: <1292678742.18.0.668231323414.issue10729@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

fwbackups is a third party package. See if you can submit a bug at http://www.diffingo.com/oss/fwbackups

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10729>
_______________________________________

From report at bugs.python.org  Sat Dec 18 15:38:57 2010
From: report at bugs.python.org (Ayman Elmasry)
Date: Sat, 18 Dec 2010 14:38:57 +0000
Subject: [issue10729] fwbackups python lib error
In-Reply-To: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>
Message-ID: <1292683137.56.0.722289442545.issue10729@psf.upfronthosting.co.za>


Ayman Elmasry <elmasry.ayman at gmail.com> added the comment:

thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10729>
_______________________________________

From report at bugs.python.org  Sat Dec 18 16:11:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Dec 2010 15:11:42 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1292685102.97.0.672349621664.issue5587@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in 3.2 (r87368) and 3.1 (r87370), thanks for the patch!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Sat Dec 18 16:17:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 18 Dec 2010 15:17:23 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1292685443.57.0.636469642448.issue9990@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll take a look at this.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Sat Dec 18 16:22:41 2010
From: report at bugs.python.org (Marc Culler)
Date: Sat, 18 Dec 2010 15:22:41 +0000
Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to
	<MouseWheel>
In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>
Message-ID: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>


New submission from Marc Culler <culler at math.uic.edu>:

In OS X tkinter the "two-finger scroll" generates <MouseWheel> events.

The following code:

#### bug.py
import tkinter

def mouse_wheel(event):
    print('Mouse wheel event')

tk = tkinter.Tk()
list = tkinter.Listbox(tk)
list.bind('<MouseWheel>', mouse_wheel)
for n in range(20):
    list.insert(tkinter.END, str(n**n))
list.pack(fill=tkinter.BOTH, expand=1)
tk.mainloop()
####

often throws a UnicodeDecodeError exception with a traceback like the one shown below when you do a "two-finger scroll" in the window.

Traceback (most recent call last):
  File "bug.py", line 12, in <module>
    tk.mainloop()
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py", line 1009, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x84 in position 1: unexpected code byte

The value of the byte changes from time to time, and sometimes it may be possible to scroll a few times without producing the error.

This problem did not occur on my Mandriva 2010.2 system.  I think it is specific to the Macintosh.  It might possibly be related to:
http://bugs.python.org/issue834351

----------
components: Tkinter
messages: 124287
nosy: culler
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in OS X tkinter when binding to <MouseWheel>
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10731>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:37:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Dec 2010 16:37:31 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292690251.84.0.362767551205.issue10573@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch changes the following things

- assertDictContainsSubset(expected, actual, msg=None)
+ assertDictContainsSubset(subset, dictionary, msg=None)
This doesn't change the order of the args, even though the name of the method might suggest the opposite.  In the output message I left expected and actual because imho it makes sense there (e.g. "key, expected: 3, actual: 5").  This could be changed to expected/got or something else.


- assertCountEqual(expected, actual, msg=None)
+ assertCountEqual(actual, expected, msg=None)
This changes the order of the args and as a consequence the list of 'missing' and 'unexpected' elements will be swapped.  The tests don't check the error message so they all pass without modification.  It should be noted that this method didn't exist in 3.1. However 2.7 has the equivalent assertItemsEqual with the args swapped, so maybe it should be documented somewhere that while porting from 2.7 to 3.2 the order of the args should be changed accordingly.


- assertDictEqual(expected, actual, msg=None)
+ assertDictEqual(dict1, dict2, msg=None)
This is just a doc change, the actual method already uses d1 and d2 as args and their order doesn't seem to matter.

The other methods (mainly the assert*Equal) are just documented with generic first/second or foo1/foo2.  The doc for these methods could be changed to use actual/expected as a preferred order.

----------
keywords: +patch
Added file: http://bugs.python.org/file20103/issue10573.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:40:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 16:40:10 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292690410.53.0.261357077986.issue10728@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r87372.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:43:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 16:43:59 +0000
Subject: [issue10729] fwbackups python lib error
In-Reply-To: <1292662172.01.0.0120827412376.issue10729@psf.upfronthosting.co.za>
Message-ID: <1292690639.85.0.943444226417.issue10729@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ayman: FYI it looks like you are trying to run the program on a Python version older than what it requires (the delete keyword for NamedTemporaryFile was introduced in version 2.6, as you can find out by looking it up in the python documentation for the tempfile module).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10729>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:46:06 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Sat, 18 Dec 2010 16:46:06 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292690766.95.0.548206400358.issue10694@psf.upfronthosting.co.za>


Kevin Hendricks <kevin.hendricks at sympatico.ca> added the comment:

Same problem exists in Python 3.1.3 and in later versions as well.

Same patch should also work.

----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:53:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Dec 2010 16:53:57 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292691237.0.0.796517532441.issue10573@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If Michael and Raymond reach a consensus, this can go in before beta2.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:54:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 16:54:28 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292691268.97.0.184715196764.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What are the media types, and are they registered with IANA?  A citation from http://www.isi.edu/in-notes/iana/assignments/media-types will be needed in order for this addition to happen if they are not x- types.

I checked out of curiousity, and the last time we added something to this table was .mp4, in 2007.

----------
nosy: +r.david.murray
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sat Dec 18 17:55:13 2010
From: report at bugs.python.org (Oren Held)
Date: Sat, 18 Dec 2010 16:55:13 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1292691313.76.0.55147884127.issue7242@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

Just adding some info:
This bug is not Solaris-specific; I reproduced it on HP-UX 11.31.

On Python 2.6.4, thread_test.py fails with the same RunTime error exception.

On Python 2.6.6, it passes and things look good.

----------
nosy: +Oren_Held

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:00:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 18 Dec 2010 17:00:11 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292691611.39.0.723487782205.issue6791@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

In the morning, I had a comment on the patch wondering why read _MAXLENGH + 1 and then check for len of header > _MAXLENGH. Instead of just reading _MAXLENGH (and if the length matched rejecting). ( Looks like it did not go through).

I think that either way is okay. I am taking the privilege of committing the patch. Fixed for py3k in 87373. So it is be available in the next beta.

Shall merge the changes to other codelines.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:01:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Dec 2010 17:01:16 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1292691676.28.0.542794752345.issue10404@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks fine, David, do you want to commit?

----------
assignee: ronaldoussoren -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:09:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 17:09:31 +0000
Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to
	<MouseWheel>
In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>
Message-ID: <1292692171.31.0.143384627439.issue10731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh -Tkinter
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10731>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:09:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 17:09:45 +0000
Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to
	<MouseWheel>
In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>
Message-ID: <1292692185.62.0.147295095562.issue10731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10731>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:11:48 2010
From: report at bugs.python.org (Grygoriy Fuchedzhy)
Date: Sat, 18 Dec 2010 17:11:48 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292692308.78.0.671263171128.issue10730@psf.upfronthosting.co.za>


Grygoriy Fuchedzhy <grygoriy.fuchedzhy at gmail.com> added the comment:

I'm not sure we are talking about the same table. I don't see .mp4 there.
    suffix_map = {
        '.tgz': '.tar.gz',
        '.taz': '.tar.gz',
        '.tz': '.tar.gz',
        '.tbz2': '.tar.bz2',
        }
*.svgz is gzipped *.svg files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:22:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 17:22:52 +0000
Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear
	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1292692972.86.0.480193696932.issue10404@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r87374, 3.1 in r87375, and 2.7 in r87376.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:35:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 17:35:52 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292693752.81.0.776299723421.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are correct, I misread your message.  However, my point still stands.  .svg is not a file extension that appears in the types_map table, so adding the line you request to the suffix_map table is not something we would do by itself.  So, to correct my question, what is the media type for '.svg'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:51:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Dec 2010 17:51:49 +0000
Subject: [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292694709.08.0.283169189935.issue10723@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r87378.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10723>
_______________________________________

From report at bugs.python.org  Sat Dec 18 18:56:45 2010
From: report at bugs.python.org (Grygoriy Fuchedzhy)
Date: Sat, 18 Dec 2010 17:56:45 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292695005.28.0.97347798875.issue10730@psf.upfronthosting.co.za>


Grygoriy Fuchedzhy <grygoriy.fuchedzhy at gmail.com> added the comment:

*.svg and *.svgz files have image/svg+xml media type.

I have following in /etc/mime.types
callisto ~ $ grep svg /etc/mime.types
image/svg+xml				svg svgz

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sat Dec 18 19:21:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 18:21:26 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1292696486.94.0.000903043135645.issue6791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Partially backported in r87382 (3.1) and r87383 (2.7). Not everything could be merged in because of HTTP 0.9 support and (in 2.7) a slightly different architecture. Thank you.

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Sat Dec 18 19:31:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Dec 2010 18:31:23 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292697083.42.0.458165431498.issue10573@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

These three changes look fine.   

The argument order for assertDictContainsSubset is problematic (doesn't match its own name and doesn't match the order for other __contains__ methods elsewhere in Python), but it's too late to change it now :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Sat Dec 18 19:31:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 18:31:45 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292697105.71.0.0379857716496.issue9286@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r87384.

Barry, I've added you as nosy in case you disagree with this fix.  The essential point is that before, parseaddr would turn 'merwok wok at example.com' into 'merwokwok at example.com', and now it preserves the whitespace.  My theory is that this loses data, that the obsolete syntax allows it, and that dropping the whitespace denies the application program the chance to apply its own heuristics.  However applications might currently be depending on the parsed local part being a single token, so I don't plan to backport this.

----------
nosy: +barry
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Sat Dec 18 19:34:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 18 Dec 2010 18:34:18 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292697258.41.0.261540714982.issue10573@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The argument order doesn't match the name (which isn't a huge deal I don't think) - but subset in dict does match the element in container order of assertIn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Sat Dec 18 19:43:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Dec 2010 18:43:24 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1292697804.97.0.336602212685.issue10716@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

There's no rush on this one.
There desired properties are:
* separate content from presentation
* validated CSS and HTML
* simple CSS so that people can *easily* customize it
* possibly offer two premade stylesheets
  1) a default beautiful one
  2) one the closely approximates the current look and feel

If the current look cannot be recreated, it should be taken as a sign that the content/presentation split wasn't done well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:11:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 19:11:49 +0000
Subject: [issue10732] Wrong destructor function type in Python/getargs.c
In-Reply-To: <1292699509.72.0.581758913937.issue10732@psf.upfronthosting.co.za>
Message-ID: <1292699509.72.0.581758913937.issue10732@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In getargs.c, in addcleanup_convert(), PyCapsule_SetContext() is called with a second argument "int (*destr)(PyObject*,void*)", but it really expects a "void (*PyCapsule_Destructor)(PyObject *)".
I'm not sure it's a good idea, although the ABI may be lenient enough on common architectures (?)...

----------
components: Interpreter Core
messages: 124307
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Wrong destructor function type in Python/getargs.c
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10732>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:25:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 18 Dec 2010 19:25:23 +0000
Subject: [issue10732] Wrong destructor function type in Python/getargs.c
In-Reply-To: <1292699509.72.0.581758913937.issue10732@psf.upfronthosting.co.za>
Message-ID: <1292700323.7.0.956375947603.issue10732@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the problem. The context is a plain void*, not (necessarily) a function pointer, and getargs uses it with the same type it put in. Why do you think PyCapsule_Destructor is of relevance?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10732>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:26:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 19:26:48 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292700408.71.0.927605605429.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This media type does not appear in the official IANA registry.  Has it not yet been officially approved?  If you want to argue that its use is common enough and its approval immanent enough (I do see that it has been submitted) to warrant inclusion in Python prior to IANA approval, I think you will have to make this case to the python-dev mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:28:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 19:28:06 +0000
Subject: [issue10732] Wrong destructor function type in Python/getargs.c
In-Reply-To: <1292700323.7.0.956375947603.issue10732@psf.upfronthosting.co.za>
Message-ID: <1292700482.3698.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I fail to see the problem. The context is a plain void*, not
> (necessarily) a function pointer, and getargs uses it with the same
> type it put in. Why do you think PyCapsule_Destructor is of relevance?

Woops, sorry. Apparently I messed up PyCapsule_SetContext and
PyCapsule_SetDestructor when reading the function declaration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10732>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:28:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 19:28:17 +0000
Subject: [issue10732] Wrong destructor function type in Python/getargs.c
In-Reply-To: <1292699509.72.0.581758913937.issue10732@psf.upfronthosting.co.za>
Message-ID: <1292700497.69.0.984176738967.issue10732@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10732>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:40:01 2010
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 18 Dec 2010 19:40:01 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

plistlib rejects control characters found in XML plists that Apple's 'plutil lint' accepts. I have attached my Terminal preferences as an example. (plistlib accepts the contents of the default Terminal preferences file)

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: com.apple.Terminal.plist
messages: 124311
nosy: MLModel, ronaldoussoren
priority: normal
severity: normal
status: open
title: plistlib rejects strings containing control characters
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20104/com.apple.Terminal.plist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Sat Dec 18 20:43:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 19:43:48 +0000
Subject: [issue10622] WebKit browsers show superfluous scrollbars in html docs
In-Reply-To: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za>
Message-ID: <1292701428.59.0.114175688245.issue10622@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Backport done in r87387 and r87388.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10622>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:01:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 18 Dec 2010 20:01:32 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1292702492.53.0.866513243687.issue10733@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is tricky. It's clearly ill-formed XML, so I'm not sure that this needs to be bug-compatible with Apple's implementation.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:03:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Dec 2010 20:03:10 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1292702590.3.0.361953791954.issue10573@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r87389. This can be backported to 3.1/2.7 where applicable.

----------
stage: needs patch -> commit review
Added file: http://bugs.python.org/file20105/issue10573.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:37:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 20:37:23 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1292704643.6.0.453280491639.issue10616@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor, I think you attached to the wrong issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:38:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 20:38:29 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1292704709.92.0.312703266918.issue10616@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor, I think you attached msg123266 to the wrong issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:38:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 20:38:35 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <1292704715.48.0.717508524821.issue10616@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg124315

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:42:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 20:42:29 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1292704949.17.0.291236849254.issue6780@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The approach looks good to me.  I think this issue is orthogonal to #10616, since the message here needs to be modified anyway, regardless of what happens to the underlying issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Sat Dec 18 21:42:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 20:42:53 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1292704973.42.0.177868496502.issue6780@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Sat Dec 18 22:15:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 21:15:22 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It looks like the Windows buildbots have been failing since the tk upgrade (at least, I'm assuming it is related since there haven't been any tk changes recently).

======================================================================
FAIL: test_heading_callback (tkinter.test.test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\tkinter\test\test_ttk\test_widgets.py", line 945, in test_heading_callback
    self.fail("The command associated to the treeview heading wasn't "
AssertionError: The command associated to the treeview heading wasn't invoked.

----------------------------------------------------------------------

(see e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x )

----------
components: Tests, Tkinter
messages: 124318
nosy: georg.brandl, gpolo, loewis, pitrou
priority: release blocker
severity: normal
status: open
title: test_ttk failure under Windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10734>
_______________________________________

From report at bugs.python.org  Sat Dec 18 22:16:52 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Dec 2010 21:16:52 +0000
Subject: [issue10727] intermittent test_cmd_line failure
In-Reply-To: <1292616329.6.0.61377155391.issue10727@psf.upfronthosting.co.za>
Message-ID: <1292707012.89.0.283164182801.issue10727@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This is a duplicate of Issue8458. Merging the nosy lists.

----------
nosy: +ned.deily
resolution:  -> duplicate
status: open -> closed
superseder:  -> buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10727>
_______________________________________

From report at bugs.python.org  Sat Dec 18 22:16:59 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 18 Dec 2010 21:16:59 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1292707019.42.0.893766079689.issue8458@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See also msg124254.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith, ncoghlan, pitrou
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Sat Dec 18 22:19:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Dec 2010 21:19:51 +0000
Subject: [issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad
	file descriptor
In-Reply-To: <1271678026.95.0.894433016298.issue8458@psf.upfronthosting.co.za>
Message-ID: <1292707191.63.0.930325276969.issue8458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Perhaps there is a race condition with cleaning up the p2c pipe from a 
> previous run?

This would be rather strange, since it would have a different file descriptor. Or it means there's a bug somewgere (perhaps in subprocess, or perhaps even in io.open).
It someone can reproduce even intermittently on their home machine, it would be nice to dig a bit deeper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Sat Dec 18 22:43:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 21:43:26 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1292708606.95.0.282799375917.issue4871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What about bytearray?  Apparently that works pre-patch for at least read, though setpassword rejects it via an assertion.

Also, the error message should be "expected bytes" rather than "bytes expected".  Don't ask me why, that's just the way it is normally done, so the other order sounds weird to this English speaker's ear.  Otherwise the py3k patch looks good and tests correctly for me.

----------
nosy: +r.david.murray
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Sat Dec 18 23:05:33 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 18 Dec 2010 22:05:33 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1292697105.71.0.0379857716496.issue9286@psf.upfronthosting.co.za>
Message-ID: <20101218170520.36ca0a54@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Dec 18, 2010, at 06:31 PM, R. David Murray wrote:

>Barry, I've added you as nosy in case you disagree with this fix.  The
>essential point is that before, parseaddr would turn 'merwok wok at example.com'
>into 'merwokwok at example.com', and now it preserves the whitespace.  My theory
>is that this loses data, that the obsolete syntax allows it, and that
>dropping the whitespace denies the application program the chance to apply
>its own heuristics.  However applications might currently be depending on the
>parsed local part being a single token, so I don't plan to backport this.

Thanks.  I agree with the fix, and not back porting it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Sat Dec 18 23:09:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 18 Dec 2010 22:09:18 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1292710158.42.0.645219232539.issue10734@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think this needs to block the beta release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10734>
_______________________________________

From report at bugs.python.org  Sat Dec 18 23:14:46 2010
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 18 Dec 2010 22:14:46 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1292710486.85.0.88900963028.issue10733@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

I can see where that does make it tricky. (I also tried reading the plist after opening the file as binary, but no luck.) The problem here, of course, is that the only reason for the existence of this library is to read Apple's plist files, however XML-invalid some may be. (It is only a small number of my very many .plist files that have invalid characters -- I just happened to pick one of them to try to access in order to print a simple summary of its contents.) I guess since the plist is read using xml.parsers.expat, there's not much that can be done, and it wouldn't be worth anyone's time to hack around this for plistlib, especially since nearly all .plist files appear to be conforming. Thanks for the clarification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Sun Dec 19 00:49:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Dec 2010 23:49:27 +0000
Subject: [issue10722] IDLE's subprocess didnit make connection ..... Python 2.7
In-Reply-To: <1292541211.42.0.50542503549.issue10722@psf.upfronthosting.co.za>
Message-ID: <1292716167.61.0.947821196343.issue10722@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not have much to add, but second the idea of inquiring on python-list or the gmane mirror, especially about alternatives (other than Notepad, which is what I started with). Happily, IDLE has nearly always worked fine on my xp machine, so I have not tried anything else.

Macs have had more problems than Windows, but perhaps Vista is worse than XP. I will be moving to Windows 7 sometime. The intermittent behavior is, I think, unusual. Please try 3.1.3 or 3.2b1 or .2b2 (in a few days) to see if there is any difference.

It is possible that we could somehow improve the error message or docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10722>
_______________________________________

From report at bugs.python.org  Sun Dec 19 03:34:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Dec 2010 02:34:11 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292726051.58.0.00722187283766.issue10730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This issue is actually a request to add .svg to the types map and the the abbreviation .svgz for .svg.gx to the suffix_map.

I believe Scalable Vector Graphics are well on the way to becoming *the* standard vector graphics format for the web, especially with upcoming IE9 support. https://secure.wikimedia.org/wikipedia/en/wiki/Svg
It (they) are already supported by the other major browsers. In addition, "Google announced on 31 August 2010 that it had begun to index SVG content on the web, whether it is in standalone files or embedded in HTML."

So it might be sensible to add these now rather than two years from now. But if it is too late for 3.2, then I expect addition for 3.3 will be obvious.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sun Dec 19 03:38:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Dec 2010 02:38:36 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292726316.54.0.604440304044.issue10730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Separate issue: from the mimetypes doc ...
"MimeTypes.types_map 
Dictionary mapping filename extensions to MIME types. This is initially a copy of the global types_map defined in the module."

But on Windows, I get a *tuple*, not a dict, of two dicts. The first has just a few pairs
>>> mi.types_map[0]
{'.xul': 'text/xul', '.pic': 'image/pict', '.pict': 'image/pict', '.jpg': 'image/jpg', '.rtf': 'application/rtf', '.pct': 'image/pict', '.mid': 'audio/midi', '.midi': 'audio/midi'}
and the second about a hundred more. Is this a bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sun Dec 19 04:24:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 19 Dec 2010 03:24:31 +0000
Subject: [issue9857] SkipTest in tearDown is reported an as an error
In-Reply-To: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>
Message-ID: <1292729071.6.0.542786629995.issue9857@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 87390.

It is a stretch to see this as a bugfix rather than a new feature so probably *shouldn't* be backported to 2.7. On the other hand the fix is combined with the fix for issue 9857 which *is* a bugfix and *should* be backported to Python 2.7.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Sun Dec 19 04:25:20 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 19 Dec 2010 03:25:20 +0000
Subject: [issue9857] SkipTest in tearDown is reported an as an error
In-Reply-To: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>
Message-ID: <1292729120.66.0.796297838306.issue9857@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Correction, the fix is combined with the fix for issue 10611.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Sun Dec 19 07:28:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 06:28:29 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

OS X Mach-O universal executable files often contain multiple architectures including a combination of 32-bit and 64-bit archs, as with the newer OS X installer variants provided on python.org.  In such cases, the platform.architecture() function always returns '64bit' as the bit architecture regardless of whether the interpreter is running in 32-bit or 64-bit mode.  Thus, there is no documented way to reliably tell whether an interpreter is running in 32- or 64-bit in OS X.  Instead of the platform module, one must resort to hacks like examining sys.maxsize (or sys.maxint) or checking type sizes from the struct module.

$ arch -x86_64 /usr/local/bin/python3.2 -c 'import sys,platform; 
print(sys.maxsize,platform.architecture())'
9223372036854775807 ('64bit', '')
$ arch -i386 /usr/local/bin/python3.2 -c 'import sys,platform; 
print(sys.maxsize,platform.architecture())'
2147483647 ('64bit', '')

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 124331
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: platform.architecture() gives misleading results for OS X multi-architecture executables
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 07:45:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Dec 2010 06:45:10 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292741110.31.0.427029296771.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think a variance from the policy stated in mimetypes is quite possible, and the kind of information you provide, Terry, is a step in that direction.  We would need release manager approval, of course, since we are in Beta, but this is a small enough change I think it would fly, assuming the policy variance is approved.

For types_map, it's a doc bug.  It is indeed a tuple of dictionaries, the first being the limited, 'strict' set and the second normally including stuff from the "standard locations", which on windows includes the registry.

So, there is an argument in favor of adding the suffix map even if the types_map isn't updated for .svg, since the .svg mapping could come from one of the 'standard locations'.  I'd rather add both, though.

----------
nosy: +georg.brandl
title: add .svgz to mimetypes.suffix_map -> add .svgz to mimetypes.suffix_map and .svg to types_map

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Sun Dec 19 07:48:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Dec 2010 06:48:09 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292741289.42.0.129504951789.issue10735@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/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 08:10:39 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 07:10:39 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292742639.88.0.864260049178.issue10735@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached patches for py3k (3.2+) and 2.7 correct platform.architecture() to return the bit architecture ('32bit' or '64bit') of the running interpreter in the default case where executable = sys.executable.  The linkage string will also contain information about the Mach-O executable including available bit- and processor-architectures as returned by the MacOS X file command.

An example of the most general results, using a 4-way build:

# ./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --with-universal-archs=all MACOSX_DEPLOYMENT_TARGET=10.5
$ file ./python
./python: Mach-O universal binary with 4 architectures
./python (for architecture i386):	Mach-O executable i386
./python (for architecture ppc7400):	Mach-O executable ppc
./python (for architecture ppc64):	Mach-O 64-bit executable ppc64
./python (for architecture x86_64):	Mach-O 64-bit executable x86_64
$ arch -i386 ./python -c 'import platform;print(platform.architecture())'
('32bit', 'MachO 32bit 64bit i386 ppc ppc64 x86_64')
$ arch -x86_64 ./python -c 'import platform;print(platform.architecture())'
('64bit', 'MachO 32bit 64bit i386 ppc ppc64 x86_64')
$ arch -ppc ./python -c 'import platform;print(platform.architecture())'
('32bit', 'MachO 32bit 64bit i386 ppc ppc64 x86_64')
$ arch -i386 ./python -m platform
Darwin-10.5.0-i386-32bit-MachO_32bit_64bit_i386_ppc_ppc64_x86_64
$ arch -x86_64 ./python -m platform
Darwin-10.5.0-i386-64bit-MachO_32bit_64bit_i386_ppc_ppc64_x86_64
$ ./python -m platform --terse
Darwin-10.5.0

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 08:11:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 07:11:07 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292742667.96.0.951861479411.issue10735@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20106/issue10735-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 08:11:39 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 07:11:39 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292742699.88.0.630102531573.issue10735@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file20107/issue10735-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 09:56:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 08:56:57 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292749017.89.0.274475294204.issue10735@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file20108/issue10735-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 09:57:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 08:57:27 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292749047.31.0.400415921468.issue10735@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file20109/issue10735-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 09:57:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 08:57:33 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292749053.31.0.161028832356.issue10735@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file20106/issue10735-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 09:57:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 08:57:37 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292749057.74.0.462419585093.issue10735@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file20107/issue10735-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 10:37:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 09:37:57 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1292751477.64.0.64601254389.issue10734@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Deferring.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10734>
_______________________________________

From report at bugs.python.org  Sun Dec 19 11:03:04 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 10:03:04 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292752984.61.0.219057687897.issue10679@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Attaching a patch that should fix it.  The delegation of the links to the Makefile is not ideal, but I don't see how to easily do it otherwise.

While this is reviewed, deferring as it should not block beta2.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Sun Dec 19 11:03:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 10:03:21 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1292753001.23.0.643105308467.issue10679@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20110/altinstall_scripts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Sun Dec 19 11:04:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 10:04:27 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1292753067.26.0.0714048752782.issue8754@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Deferring, this is not a bug.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Sun Dec 19 11:11:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 10:11:34 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1292753494.88.0.529623555977.issue6075@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've committed in the py3k branch as r87394, so that this can get testing during beta, although your list of test systems looks quite exhaustive already.  Lowering priority and leaving open for the backports.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Sun Dec 19 11:33:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 10:33:21 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1292754801.28.0.0379979924507.issue10734@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I disabled the test temporarily in r87395 -- it needs to be reenabled after fixing this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10734>
_______________________________________

From report at bugs.python.org  Sun Dec 19 11:52:37 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 19 Dec 2010 10:52:37 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292755957.0.0.559979637595.issue3243@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is committed in r87399. Documentation and NEWS is added. Thanks for the patch and review comments.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 13:24:34 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 12:24:34 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292761474.42.0.634091972667.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hello, sorry for commenting on a closed issue... but I think the documentation change is incorrect. In urllib.request.rst, it says data is a string. However as seen in the changes to test_urllib2.py, data must be a bytes object rather than a string object. I think we should reopen this issue and change the documentation.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 13:28:52 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 12:28:52 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292761732.0.0.144158045662.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Also, the patch for request.py contains a debug statement, print(data)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 13:34:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 12:34:05 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292762045.79.0.890145747171.issue3243@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Good catch, fixed in r87400.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 13:47:12 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 12:47:12 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292762832.19.0.983217019816.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Also, I am not familiar with the backward-comparability requirements of py3k, but orsenthil's patch will break py3k code that relies on data being a string, shouldn't this be mentioned somewhere?

Finally, I do not understand why my proposed change, which is to add

+    if not data:
+        request.add_unredirected_header('Content-length', '0')


so that code that relies on being able to pass a blank string as data (for instance, the code in test_urllib2.py) is still able to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 13:58:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 12:58:53 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292763533.61.0.398234841263.issue3243@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, indeed: Senthil, could data be a string in earlier versions?

If yes, the code should be changed to still allow that.  (But after beta2 please, it's already tagged.)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:03:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 13:03:18 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292763798.89.0.482505548609.issue3243@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Raising priority so that this gets sorted out before final.

----------
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:22:01 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 13:22:01 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292764921.49.0.524651141014.issue10680@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:25:05 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 13:25:05 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292765105.19.0.475632919779.issue9938@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:27:37 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 13:27:37 +0000
Subject: [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292765257.4.0.592164232748.issue10702@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10702>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:29:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 13:29:55 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

3.2b2(~)

The following two test failures are seen with the newly released Cocoa-based ActiveState Tcl 8.5.9 on OS X 10.6.  No failures are reported when using the Apple Tcl/Tk 8.5 supplied with 10.6.

======================================================================
ERROR: test_tab_identifiers (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/test/test_ttk/test_widgets.py", line 564, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/ttk.py", line 318, in _val_or_dict
    res = func(*(args + options))
_tkinter.TclError: tab '@5,5' not found

======================================================================
FAIL: test_traversal (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tkinter/test/test_ttk/test_widgets.py", line 726, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.4654766160' != '.4654766352'
- .4654766160
?         ^^^
+ .4654766352
?         ^^^

Also multiple instances of the following apparently harmless message appear when using the ActiveState 8.5.9 Tcl:

setCanCycle: is deprecated.  Please use setCollectionBehavior instead

This is likely due to an upstream build problem from ActiveState.

http://permalink.gmane.org/gmane.comp.lang.tcl.mac/6524

----------
assignee: ned.deily
components: Macintosh, Tests, Tkinter
messages: 124346
nosy: ned.deily, ronaldoussoren
priority: deferred blocker
severity: normal
status: open
title: test_ttk_guionly fails on OS X using ActiveState Tcl 8.5.9 (Cocoa)
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:31:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 13:31:06 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1292765466.39.0.486692990975.issue10736@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:32:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Dec 2010 13:32:45 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This has been happening recently on our Windows Server 2008 buildbot:


======================================================================
FAIL: test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 252, in test_first_completed
    self.assertEqual(set([future1]), done)
AssertionError: Items in the second set but not the first:
<Future at 0x19899f60 state=finished raised AssertionError>

======================================================================
FAIL: test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 293, in test_first_exception
    self.assertEqual(set([future1, future2]), finished)
AssertionError: Items in the second set but not the first:
<Future at 0x164e5878 state=finished raised AssertionError>

======================================================================
FAIL: test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 323, in test_first_exception_some_already_complete
    future1]), finished)
AssertionError: Items in the second set but not the first:
<Future at 0x16f9b948 state=finished raised AssertionError>

======================================================================
FAIL: test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_concurrent_futures.py", line 442, in test_timeout
    future1]), finished)
AssertionError: Items in the second set but not the first:
<Future at 0xd0efe28 state=finished raised AssertionError>


(see e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/306/steps/test/logs/stdio )

----------
assignee: bquinlan
components: Library (Lib), Tests
messages: 124347
nosy: bquinlan, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_concurrent_futures failure on Windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10737>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:34:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 13:34:48 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1292765688.77.0.818242844515.issue10737@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10737>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:35:01 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Dec 2010 13:35:01 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1292765701.67.0.861522345856.issue10736@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Are you in a position to debug this a bit more?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:35:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Dec 2010 13:35:58 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292765758.05.0.185651069746.issue10735@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Instead of the platform module, one must resort to hacks like examining 
> sys.maxsize

I'm not sure why you think it's a hack. To me, it's, by construction, the right way to check for 64-bitness (and also the easiest since it doesn't involved parsing of strings of an unspecified format).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:40:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 13:40:38 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1292766038.53.0.282646357677.issue10736@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I'll look into it.  No need to hold up beta2 for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:49:09 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 19 Dec 2010 13:49:09 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292766549.81.0.488350728799.issue10735@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's only a hack in the sense that platform.architecture is the documented interface in the std library to report "bits" and, unfortunately, users try to use it to determine whether running in 64-bit or 32-bit mode.  For instance, see here:
http://permalink.gmane.org/gmane.comp.python.general/676626

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 14:56:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Dec 2010 13:56:38 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292766549.81.0.488350728799.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292766991.3679.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It's only a hack in the sense that platform.architecture is the
> documented interface in the std library to report "bits" and,
> unfortunately, users try to use it to determine whether running in
> 64-bit or 32-bit mode.  For instance, see here:
> http://permalink.gmane.org/gmane.comp.python.general/676626

Well, the fact that platform.architecture() returns a free-form string
suggests to me that it could return all kinds of unexpected results
depending on the system (it probably parses the output of some command).
So perhaps the platform docs should warn against this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Sun Dec 19 15:14:29 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 14:14:29 +0000
Subject: [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292768069.88.0.290792063182.issue10702@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi, it seems to me that section 4.6.5. Bytes and Byte Array Methods covers this already. It says:

Bytes and bytearray objects, being ?strings of bytes?, have all methods found on strings, with the exception of encode(), format() and isidentifier(), which do not make sense with these types. For converting the objects to strings, they have a decode() method.

Wherever one of these methods needs to interpret the bytes as characters (e.g. the is...() methods), the ASCII character set is assumed.

This section covers belpolsky's needs, ie a reader can, from this, understand that bytes have a capitalize method. However, I support

1) Expanding this section to explain more clearly what the methods do to bytes
2) Discuss unicode vs bytes details
3) Mention bytes and bytearrays in 4.6.1 String Methods, because it is quite far away from 4.6.5

As for the suggestion of renaming, if we rename the section, we have to decide what to call a string/byte/bytearray object because it now says, for example, str.something(); also we have to document the encode and decode methods seperately because they are not common to strings and bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10702>
_______________________________________

From report at bugs.python.org  Sun Dec 19 15:19:41 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 19 Dec 2010 14:19:41 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292768381.64.0.133118722718.issue10515@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I get two failures with David's latest patch.  Abstracting from
a lightly modified patch:

    sample was: 'a,b,"c,d"\r\ne,f,g', got: '', expected: ','
    sample was: '"a,b,c,d"\r\ne', got: '\r', expected: ''

In both cases I think the expected delimiter should be comma.
The code or regular expressions need to be fixed for the first
failure.  As I indicated earlier \r\n should never be split.
Also, for a single column CSV file I think the expected/default
delimiter should be a comma.

That said, does anyone think I should change the expected delimiter
for the first two tests at this point for 2.7?  The inputs and
expected delimiters are

    ('abcde', 'e'),
    ('a', 'e'),

Both seem wrong to me, but I understand that the behavior of 2.7
probably shouldn't change to accommodate fixing broken test cases.

I'm also a bit concerned about this construct:

    locals()['some name'] = f

I thought locals() wasn't guaranteed to actually refer to a 
persistent dictionary.  That is, it's fine if locals() builds
its dictionary on-the-fly then discards it.  Do we know for
a fact that when called during a class definition that locals()
returns the class's dictionary?  (This might only matter if
other dialects of Python try to reuse test_csv.py.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sun Dec 19 15:46:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 19 Dec 2010 14:46:44 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1292770004.97.0.0754104101588.issue3243@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Xuanji, Thanks for the comments on 'data' being bytes. I had just cared to add the feature information. I think that data detail should have been updated too. 

I think for your other two questions, we discussed it msg123051 - socket in py3k handles only bytes, sending string was wrong and test_urllib2 had the mistake in sending zero length strings which weren't detected.

However, let me see if we have to accommodate those "very special case" where data can be a zero length string just to accommodate the mistake it was present in the earlier version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Dec 19 15:56:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 19 Dec 2010 14:56:31 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1292770591.05.0.429726976715.issue10611@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed to Python 2.7 in revision 87406.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10611>
_______________________________________

From report at bugs.python.org  Sun Dec 19 16:00:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 19 Dec 2010 15:00:24 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1292770824.68.0.543991593458.issue10611@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed to py3k in revision 87390.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10611>
_______________________________________

From report at bugs.python.org  Sun Dec 19 16:05:23 2010
From: report at bugs.python.org (NE1)
Date: Sun, 19 Dec 2010 15:05:23 +0000
Subject: [issue10738] webbrowser.py bug with Opera on Linux
In-Reply-To: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>
Message-ID: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>


New submission from NE1 <garberr at verizon.net>:

Tested with Python 2.7.1 / Linux 2.6.33.2 / Opera 10.63. Build 6450 for Linux

class Opera(UnixBrowser) shows:
raise_opts = ["", "-raise"]

"-raise" is not a valid command line option for Opera.

This causes all webbrowser open methods (that use autoraise=True by default) to not work correclty with Opera (webbrowser.open returns True, but Opera does not open, etc).

The raise options should probably be changed to:
raise_opts = ["-noraise", ""]

Opera - UNIX Command Line Options: http://www.opera.com/docs/switches/#unix

----------
messages: 124358
nosy: NE1
priority: normal
severity: normal
status: open
title: webbrowser.py bug with Opera on Linux
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10738>
_______________________________________

From report at bugs.python.org  Sun Dec 19 16:16:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 19 Dec 2010 15:16:09 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292771769.19.0.0872694390124.issue10515@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that the unquoted single column cases look weird. But changing it could affect other cases were there is more data.  I'll leave that problem to you :)  But I do not think that should be backported.

The locals trick I stole from Barry. I think there ought to be a way to get at the class dict as the class is being built. But you are right that the docs imply that locals is not guaranteed to be it.  Perhaps a topic for python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sun Dec 19 16:53:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 19 Dec 2010 15:53:52 +0000
Subject: [issue10242] unittest's assertItemsEqual() method makes too many
	assumptions about its input
In-Reply-To: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>
Message-ID: <1292774032.4.0.0729580322935.issue10242@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Improved implementation committed to 2.7 revision 87407. Method name unchanged there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Sun Dec 19 16:55:44 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 19 Dec 2010 15:55:44 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292774144.39.0.615692024621.issue10515@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Also, this comment in test_csv.py puzzles me:

        # given that all three lines in sample3 are equal,
        # I think that any character could have been 'guessed' as the
        # delimiter, depending on dictionary order

As a human looking at sample3 it's obvious the '?' should
be the delimiter.  I can understand it picking '/' instead,
but it shouldn't punt.  (I stumbled upon this while trying
to make "," be the default delimiter instead of None when
none of the regular expressions matched.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sun Dec 19 17:00:00 2010
From: report at bugs.python.org (Ron Adam)
Date: Sun, 19 Dec 2010 16:00:00 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1292774400.54.0.869238338799.issue8916@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8916>
_______________________________________

From report at bugs.python.org  Sun Dec 19 17:00:43 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 19 Dec 2010 16:00:43 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1292774443.22.0.893830852841.issue10515@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Here's my candidate patch.  Instead of returning an empty string
as the delimiter it returns a comma.

----------
Added file: http://bugs.python.org/file20111/csv_delimiter_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Sun Dec 19 17:47:54 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 19 Dec 2010 16:47:54 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292777274.61.0.973950141069.issue10461@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


Removed file: http://bugs.python.org/file19671/logging.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sun Dec 19 18:43:23 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 19 Dec 2010 17:43:23 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292780603.92.0.0893553014591.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

following re-organization of the logging docs, I'm attaching updated patch.

----------
nosy: +vinay.sajip
Added file: http://bugs.python.org/file20112/logging-cookbook.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sun Dec 19 22:59:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Dec 2010 21:59:49 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292795989.66.0.0930860373063.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why was sys.setsegfaultenabled() omitted?

Just because I forgot your message, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Sun Dec 19 23:02:53 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 19 Dec 2010 22:02:53 +0000
Subject: [issue8073] Test fail for sha512 -
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1292796173.86.0.626601801335.issue8073@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

In your back traces notice that the size= argument is clearly nonsensical.

Regardless, i can't reproduce this on any of my systems (I don't have a suse system of any sort).  If that is the only place you are seeing this I strongly suspect you've got something going on there.

Without some way to reproduce this or more detailed debugging info (point to the line of python that dies and single step into the C code in gdb from there printing out relevant state along teh way to see what happens) there is nothing I can do.

----------
resolution:  -> works for me
status: open -> closed
title: Test fail for sha512 -> Test fail for sha512 -

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8073>
_______________________________________

From report at bugs.python.org  Sun Dec 19 23:05:29 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 19 Dec 2010 22:05:29 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1292796329.34.0.987742683591.issue3566@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

unassigning, i don't had time to look at this one.

----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Mon Dec 20 00:19:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Dec 2010 23:19:12 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292800752.08.0.202701493442.issue10461@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Vinay, you should look at the logging-cookbook patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Mon Dec 20 00:35:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Dec 2010 23:35:57 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292801757.58.0.268693184152.issue10728@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This apparently lacks a 2.7 backport.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Mon Dec 20 00:41:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Dec 2010 23:41:08 +0000
Subject: [issue10663] configure shouldn't set a default OPT
In-Reply-To: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>
Message-ID: <1292802068.19.0.0868527152732.issue10663@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10663>
_______________________________________

From report at bugs.python.org  Mon Dec 20 00:43:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Dec 2010 23:43:04 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1292802184.95.0.255672712388.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If nobody objects, I will commit this when py3k is unfrozen.

----------
assignee:  -> eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Dec 20 00:45:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Dec 2010 23:45:04 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292802304.15.0.622144565894.issue10680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What I?m saying is: If you would like to contribute a patch, here are some helpful guidelines to follow.  They help you getting set up and catch some common errors, and they help us review the patch to accept or comment it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Mon Dec 20 00:53:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Dec 2010 23:53:22 +0000
Subject: [issue9286] email.utils.parseaddr returns garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1292802802.06.0.817430656234.issue9286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the explanations and fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:01:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Dec 2010 00:01:55 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292803315.51.0.259286954047.issue10694@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the suggested code. As suggested, it would be helpful to supply a complete patch (or patches) ready to be reviewed and applied to the tips of the currently maintained source trees (py3k, 3.1, and 2.7) including adding an appropriate test case to Lib/test/test_zipfile.py.

----------
nosy: +alanmcintyre, ned.deily
stage:  -> needs patch
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:04:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 20 Dec 2010 00:04:11 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1292803451.01.0.899663047369.issue3566@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:10:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Dec 2010 00:10:17 +0000
Subject: [issue10738] webbrowser.py bug with Opera on Linux
In-Reply-To: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>
Message-ID: <1292803817.01.0.692611636079.issue10738@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10738>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:12:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Dec 2010 00:12:38 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292803958.73.0.767943098822.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 10 of my patch:
 - the fault handler restores the previous signal handler instead of calling (DebugBreak() and) abort(): the previous signal handler will be called later to keep the orignal behaviour
 - _testcapi.sigill() and _testcapi.sigbus() send SIGILL/SIGBUS signal in an unlimited loop instead of sending the signal once. So the signal is sent again after calling the Python signal handler, and the previous signal handler is called
 - (minor change) use 2 arrays (fault_handlers and fault_signals) for all signals, instead 2 variables (xxx_enabled, xxx_handler) for each signal

With this patch, the original signal handler is called and so the Python fault handler is compatible with OS fault handlers like grsecurity and Apport.

----------
Added file: http://bugs.python.org/file20113/segfault_handler-10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:21:02 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Mon, 20 Dec 2010 00:21:02 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292804462.31.0.819326335224.issue10694@psf.upfronthosting.co.za>


Kevin Hendricks <kevin.hendricks at sympatico.ca> added the comment:

Final patches against the trees make no sense as no developer has decided which way they want to actually handle the problem. 

My patch is only one way and I note it may not be the way the owners of the code want.

Also, this patch is very straight forward (one hunk) and should apply to 2.6, 2.7, and 3.1 (although I have not tried it with 3.1) with only line offsets.

So if the owner of this code actually looks that the patch and the bug report and makes a decision on how they want to handle this issue and they like the patch I have suggested, then I would be happy to diff it against whatever zipfile.py versions he/she wants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:34:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Dec 2010 00:34:08 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292805248.58.0.967846065248.issue10680@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The problem is that the nested group doesn't share/propagate mutually exclusive groups with its parent container. The attached patch fixes this.

----------
keywords: +patch
Added file: http://bugs.python.org/file20114/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Mon Dec 20 01:51:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Dec 2010 00:51:33 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292806293.27.0.64653489151.issue10735@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Adding a warning sounds like a good idea.  Is it reasonable to include a recommended cross-platform approach in the platform doc, like either the sys.maxsize test or the struct.calsize("P") test (which is used as a default fallback in platform.architecture)?  Are there any currently supported platforms where either of those wouldn't work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Mon Dec 20 02:14:14 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Dec 2010 01:14:14 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292807654.29.0.747350795999.issue10694@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Not to belabor the point but the most useful part of a ready-to-go patch would be to have a fully automated test case that fits into the existing test_zipfile.py structure and that demonstrates the failure. Somebody has to write a test case one way or another because that's the first step towards getting a fix applied. That can be a big help as there are many more modules in the standard library than there are volunteer core developers to look at problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 02:22:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 01:22:11 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292808131.21.0.324027325657.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually our normal procedure currently (this will change a bit after the migration to mercurial) is a patch against the py3k branch, and the committer will do the backport to the other active branches.  If the 2.7 code is very different, a separate 2.7 patch is sometimes helpful.  In this case it looks like a patch that applies to py3k is enough.

Alan hasn't spoken up yet, and he's listed as maintainer.  If he doesn't speak up someone else will hopefully make a decision before the end of the beta period for 3.2.  I'm bumping up the priority of this issue because I think not being able to handle commonly produced archives that other zip tools can handle is a relatively serious defect.

My own opinion is that truncation if the extra data doesn't look like a comment makes the most sense.  But absent an opinion from Alan I think I'd be guided by whatever other zip tools do in this case.  Kevin, am I correct in guessing that that is truncation?

Ned is definitely correct that absence of a test case is something that can delay getting a patch applied.  If a patch includes a unit test, a committer can often do a quick review-and-apply, while absent a unit test the committer would first need to write one, and therefore will often move on to some other, easier to process issue :)  In this case it seems to me that the unit test will only differ in one detail depending on the fix chosen, so it may be worth writing it even before a final decision is made, if you are willing.

----------
nosy: +r.david.murray
priority: normal -> high
stage: needs patch -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 02:24:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 01:24:45 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292808285.87.0.131620492022.issue10728@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Like Georg, I'll get to that when I do a mass backport of all my doc fixes.  My apologies for missing the beta2 deadline on doing that, but there aren't many of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Mon Dec 20 02:37:50 2010
From: report at bugs.python.org (Chris Lieb)
Date: Mon, 20 Dec 2010 01:37:50 +0000
Subject: [issue8073] Test fail for sha512 -
In-Reply-To: <1267805255.09.0.582618430445.issue8073@psf.upfronthosting.co.za>
Message-ID: <1292809070.38.0.0798980124442.issue8073@psf.upfronthosting.co.za>


Chris Lieb <chris.lieb.hotmail+python at gmail.com> added the comment:

I don't have any way to test this anymore since they removed pretty much the entire toolchain on that server and I really don't feel like trying to get an entire toolchain built and installed just to test this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8073>
_______________________________________

From report at bugs.python.org  Mon Dec 20 04:13:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 03:13:00 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1292814780.71.0.0627897352006.issue10733@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Mon Dec 20 07:55:07 2010
From: report at bugs.python.org (Scott Dial)
Date: Mon, 20 Dec 2010 06:55:07 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292828107.97.0.400321178124.issue8863@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

FYI, in v10,

+#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0]))
+static fault_handler_t fault_handlers[4];

, should use "NFAULT_SIGNALS" instead of "4".

However, this bit of code bothers me a lot:

+    const int fd = 2; /* should be fileno(stderr) */

To assume that fd=2 is the write place to be writing bytes is assuming quite a bit about the state of the application. It is not unusual at all to close 0,1,2 when writing daemons, which frees them up to be assigned to *anything*. For all you know, fd=2 currently is a network socket that you will be throwing gibberish at, or worse it could be a block device that you are writing gibberish on.

The closest discussion I could find on this subject was on the libstdc++ mailing-list with regard to their verbose termination code:

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02388.html

AFAICT, their conclusion was that the only reasonable solution was to write to the stderr FILE since it was the only thing that is guaranteed to make sense always (even though it may fail). Their situation is different in that they are handling a C++ exception, so they don't have to stick to async-safe functions, but absent that extra difficulty, I believe the reasoning is the same.

The analogous situation exists in Python, in that sys.stderr(*) represents where the application programmer expects "stderr" writing to go. I think you need to arrange to know what the fd number for that object is or this patch is unacceptable in the vein of "wrote garbage to my harddrive and destroyed my data" sort.

I'm not sure there is a safe way to know what the fileno for "sys.stderr" is because it can be anything, including an object whose fileno changes over time. However, I think it would be fair to support only built-in io types that are obviously safe, since you could cache the fileno() value at assignment to use in your fault handler.

(*) Or perhaps __stderr__ if stderr is None or an unsupported type?

----------
nosy: +scott.dial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Dec 20 08:29:17 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 07:29:17 +0000
Subject: [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

On Windows, creating a subprocess does not work when stdin (or stdout or stderr) is set as a file object created from socket.makefile(). An IOError is thrown.

This works fine on Unix so I assume it is a platform limitation rather than a Python bug.

If this is so then this should be documented under the subprocess module.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: test.py
messages: 124382
nosy: docs at python, rosslagerwall
priority: normal
severity: normal
status: open
title: Subprocess behavior on Windows
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20115/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10739>
_______________________________________

From report at bugs.python.org  Mon Dec 20 08:30:14 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 07:30:14 +0000
Subject: [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292830214.86.0.111198866684.issue10739@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch to document this.

----------
keywords: +patch
Added file: http://bugs.python.org/file20116/subprocessdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10739>
_______________________________________

From report at bugs.python.org  Mon Dec 20 10:35:25 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Dec 2010 09:35:25 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292837725.48.0.829548294702.issue10461@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've already made the change, Terry, just holding off committing it because Georg has frozen the py3k branch until 3.2b2 is released.

There are a few other changes I'm making, will commit these soon after 3.2b2 is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Mon Dec 20 13:33:43 2010
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 20 Dec 2010 12:33:43 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292848423.3.0.833714541658.issue4761@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Mon Dec 20 14:30:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Dec 2010 13:30:57 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1292828107.97.0.400321178124.issue8863@psf.upfronthosting.co.za>
Message-ID: <201012201430.52068.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le lundi 20 d?cembre 2010 07:55:08, vous avez ?crit :
> +#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0]))
> +static fault_handler_t fault_handlers[4];
> 
> , should use "NFAULT_SIGNALS" instead of "4".

Ah yes, NFAULT_SIGNALS is a better choice than the maximum of possible signals 
(4).

> However, this bit of code bothers me a lot:
> 
> +    const int fd = 2; /* should be fileno(stderr) */
> 
> To assume that fd=2 is the write place to be writing bytes is assuming
> quite a bit about the state of the application. It is not unusual at all
> to close 0,1,2 when writing daemons, which frees them up to be assigned to
> *anything*.

Write into a closed file descriptor just does nothing. Closed file descriptors 
are not a problem.

> For all you know, fd=2 currently is a network socket that you
> will be throwing gibberish at, or worse it could be a block device that
> you are writing gibberish on.

The GNU libc has also a fault handler (source code: debug/segfault.c). It uses 
the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is 
set (value stored in "fname" variable): open the specified file.

  /* This is the name of the file we are writing to.  If none is given
     or we cannot write to this file write to stderr.  */
  fd = 2;
  if (fname != NULL)
    {
      fd = open (fname, O_TRUNC | O_WRONLY | O_CREAT, 0666);
      if (fd == -1)
	fd = 2;
    }

The GNU libc installs handlers for SIGSEGV, SIGILL, SIGBUS, SIGSTKFLT, 
SIGABBRT and SIGFPE signals. The handler restores the default handler and re-
raise the signal:

  /* Pass on the signal (so that a core file is produced).  */
  sa.sa_handler = SIG_DFL;
  sigemptyset (&sa.sa_mask);
  sa.sa_flags = 0;
  sigaction (signal, &sa, NULL);
  raise (signal);

Where "raise(signal);" is something like kill(getpid(), signal).

It only uses an alternate stack if SEGFAULT_USE_ALTSTACK environment variable 
is set.

The handler can display registers, the backtrace and the memory mappings, 
depending on the compilation options and the operating system.

> The closest discussion I could find on this subject was on the libstdc++
> mailing-list with regard to their verbose termination code:
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02388.html
> 
> AFAICT, their conclusion was that the only reasonable solution was to write
> to the stderr FILE since it was the only thing that is guaranteed to make
> sense always (even though it may fail). Their situation is different in
> that they are handling a C++ exception, so they don't have to stick to
> async-safe functions, but absent that extra difficulty, I believe the
> reasoning is the same.

The FILE* type cannot be used because fprintf(), fputs(), ... are not signal-
safe.

> I'm not sure there is a safe way to know what the fileno for "sys.stderr"
> is because it can be anything, including an object whose fileno changes
> over time

The signal handler cannot access the Python object. Eg. if sys.stderr is a 
StringIO() (which has no file descriptor), it cannot be used.

> However, I think it would be fair to support only built-in io
> types that are obviously safe, since you could cache the fileno() value at
> assignment to use in your fault handler.

The problem is to detect that stderr file descriptor changes (eg. closed, 
duplicated, reopened, etc.). I don't think that it's possible to detect such 
changes (with a portable function).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Dec 20 14:40:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 13:40:14 +0000
Subject: [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292852414.48.0.219463658316.issue10739@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This might be an example of the general problem that on windows, sockets and files don't mix well.  You can't use a file in a select call, either.

I think there are two possibilities here: either makefile doesn't produce anything very useful on windows, or there's a bug in either makefile or subprocess.  If the former, the proper place to document it would be in the makefile docs.

----------
assignee: docs at python -> 
nosy: +brian.curtin, gregory.p.smith, r.david.murray, tim.golden
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10739>
_______________________________________

From report at bugs.python.org  Mon Dec 20 15:06:36 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Mon, 20 Dec 2010 14:06:36 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292853996.74.0.634257340802.issue10694@psf.upfronthosting.co.za>


Kevin Hendricks <kevin.hendricks at sympatico.ca> added the comment:

I have not looked at how other tools handle this.  They could simply ignore what comes after a valid endrecdata is found, they could strip it out (truncate it) or make it into a final comment.  I guess for simply unpacking a zip archive, all of these are equivalent (it goes unused).

But if you are copying a zip archive to another archive then ignoring it and truncating it may be safer in some sense (since you have no idea what this extra data is for and why it might be attached) but then you are not being faithful to the original but at the same time you do not want to create improper zip archives.  If you change the extra data into a final comment, then at least none of the original data is actually lost (just moved slightly in the copied zip and protected as a comment) and could be recovered if it turns out to have been useful.  With so many things using/making the zip archive format (jars, normal zips, epubs, etc) you never know what might have been left over at the end of the zip file and if it was important.

So I am not really sure how to deal with this properly.  Also I know nothing about _EndRecData64 and if it needs to somehow be handled in a different way.

So someone who is very familiar with the code should look at this and tell us what is the right thing to do and even if the approach I took is correct (it works fine for me and I have taken to including my own zipfile.py in my own projects until this gets worked out) but it might not be the right thing to do.

As for a test case, I know nothing about that but will look at test_zipfile.py.  I am a Mac OS X user/developer so all of my code is targeted to running on both Python 2.5 (Mac OS X 10.5.X) and Python 2.6 (Mac OS 10.6.X). Python 3.X and even Python 2.7 are not on my horizon and not even on my build machine (trying to get Mac OS X users to install either would be an experience in frustration). I simply looked at the source in Python 2.7 and Python 3.1.3 (from the official Python releases from python.org) to see that the problem still exists (and it does).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 15:25:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Dec 2010 14:25:55 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1292855155.07.0.778415550247.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The fault handler is unable to retrieve the thread state if the GIL is released. I will try to fix that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Dec 20 16:07:22 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 15:07:22 +0000
Subject: [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292857642.86.0.104789519846.issue10739@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Since the code in subprocess gets the underlying fileno of the file-like object (line 819 of subprocess.py), I presume it is an example of the general problem of files and sockets not mixing very well on Windows.

So, I have attached a patch to document this in socket.makefile().

However, I also see that *it* is documented in select.select() that it will not work with Windows file-like objects. Maybe there should still be a note in subprocess.Popen() as per the first patch?

----------
Added file: http://bugs.python.org/file20117/socketdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10739>
_______________________________________

From report at bugs.python.org  Mon Dec 20 16:52:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 15:52:18 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292860338.53.0.18965236562.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's pretty easy, really, to do an SVN checkout of python and compile it on a mac, if you are at all familiar with the unix command line.  If you don't have the time or desire for that, though, someone will eventually get to it, we just don't know when ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 17:24:23 2010
From: report at bugs.python.org (Kevin Hendricks)
Date: Mon, 20 Dec 2010 16:24:23 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292862263.26.0.587061498258.issue10694@psf.upfronthosting.co.za>


Kevin Hendricks <kevin.hendricks at sympatico.ca> added the comment:

Been programming on unix/vax and then linux since the mid 80s and on punch cards in the late 70s.  Grew my first beard writing 8080 and Z80 assembler.  All of that was over 30 years ago. 

All I want to do is report a damn bug!

Then I get nudged for a test case (although how to recreate the bug was already described) so I add the two lines to create a test case.  

Then I get nudged for a patch, so I give a patch even though there are many ways to deal with the issue.

Then I get nudged for patches for other branches, then I get nudged for official test_zipfile.py patches.

All of this **before** the damn owner has even bothered to look at it and say if he/she even wants it or if the patch is even correct.

I have my own working code for the epub ebook stuff I am working on so this issue no longer impacts me.

How did I go from a simple bug report to having to build python's latest checkout just to get someone to look at the bug.

You have got to be kidding me!

I am done here,  do what you want with the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 17:55:24 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 20 Dec 2010 16:55:24 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1292864124.84.0.100174135503.issue10087@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:02:16 2010
From: report at bugs.python.org (Scott Urban)
Date: Mon, 20 Dec 2010 18:02:16 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>


New submission from Scott Urban <scott.urban at isilon.com>:

The python sqlite module automatically commits open transactions
when it encounters a DDL statement.  This is unnecessary; DDL is
transactional in my testing (see attached).

Attached patch addresses the issue. Patch is against 2.6.1, but
looking at Trunk in svn, it seems like the patch is needed and
would apply. One issue I could foresee is that this behavior might
depend on the sqlite version in use (I'm on 3.6.10).

Patch also allows pragma statement.

----------
components: Library (Lib)
files: pysql-transactions.2.diff
keywords: patch
messages: 124392
nosy: scott.urban
priority: normal
severity: normal
status: open
title: sqlite3 module should allow DDL statements in transactions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20118/pysql-transactions.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:03:42 2010
From: report at bugs.python.org (Scott Urban)
Date: Mon, 20 Dec 2010 18:03:42 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1292868222.45.0.278949740852.issue10740@psf.upfronthosting.co.za>


Scott Urban <scott.urban at isilon.com> added the comment:

Here are some tests.

----------
Added file: http://bugs.python.org/file20119/test_sqlite_ddl.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:09:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Dec 2010 18:09:52 +0000
Subject: [issue10741] PyGILState_GetThisThreadState() lacks a doc entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

PyGILState_GetThisThreadState() is "documented" in Include/pystate.h but not in the official docs. It should be documented along PyGILState_Ensure() and friends.

----------
assignee: docs at python
components: Documentation
messages: 124394
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: PyGILState_GetThisThreadState() lacks a doc entry
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10741>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:14:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 18:14:57 +0000
Subject: [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292868897.34.0.0283289362229.issue10739@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think I'll leave that decision up to the doc crew.  My thought was that makefile was supposedly returning a file, therefore it was appropriate to document there that it wasn't really a file on windows, whereas subprocess docs are only talking about files, and it only just so happens that you can pass it a socket on unix by using makefile.

----------
assignee:  -> docs at python
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10739>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:19:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 18:19:21 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292869161.04.0.366674092897.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, I thought I was being clear that if you *wanted* to help further here was how you could, but if you didn't then we'd get to it eventually.  We're all volunteers here, just like you, so every bit of help...helps, and we thank you sincerely for taking the time to report the bug and provide the preliminary patch and test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:31:55 2010
From: report at bugs.python.org (Scott Dial)
Date: Mon, 20 Dec 2010 18:31:55 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <201012201430.52068.victor.stinner@haypocalc.com>
Message-ID: <4D0FA0EF.9040002@scottdial.com>


Scott Dial <scott at scottdial.com> added the comment:

On 12/20/2010 8:30 AM, STINNER Victor wrote:
> Write into a closed file descriptor just does nothing. Closed file descriptors 
> are not a problem.

My issue not with a closed file descriptor, it is with an open file
descriptor that is not what you think it is.

>> For all you know, fd=2 currently is a network socket that you
>> will be throwing gibberish at, or worse it could be a block device that
>> you are writing gibberish on.
> 
> The GNU libc has also a fault handler (source code: debug/segfault.c). It uses 
> the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is 
> set (value stored in "fname" variable): open the specified file.

The GNU libc segfault handler is *opt-in* via the SEGFAULT_SIGNALS
environment variable. I do not know of a system where SEGFAULT_SIGNALS
is a part of the default environment. I suspect the only time anyone
uses that variable and code is if they are using the "catchsegv" tool,
which comes with glibc. In any case, that developer should be aware of
the implication of closing fd 2.

> The FILE* type cannot be used because fprintf(), fputs(), ... are not signal-
> safe.

My point was that in C++, they have an object that an application
developer more readily associates with "stderr" than fd 2. That writing
to "stderr" leads to a write to fd 2 is incidental, because it's
possible that "stderr" does *not* lead to a write to fd 2 and that
writing to fd 2 would be a bad thing to do blindly. For instance, you
can call freopen(path, mode, stderr) and fd 2 will end up closed and
another fd will be the target of stderr. I don't believe POSIX
guarantees that open() will not re-use fd 2.

> The problem is to detect that stderr file descriptor changes (eg. closed, 
> duplicated, reopened, etc.). I don't think that it's possible to detect such 
> changes (with a portable function).

When I said that, I hadn't fully investigated the intricacies of the io
types. I was unaware that you could assign to "sys.stderr.buffer.raw"
and change out the target fd. I assumed a BufferedWriter could not have
the target stream changed out from beneath it. So, I don't have a
solution to the problem of knowing the correct (if any) file descriptor
to write to.

If the argument is made that fd 2 is the right place for most Python
applications, then there needs to be a programmatic way to disable this
feature and/or tell it where to write, so that programs that daemonize
can do the right thing.

----------
title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV,	SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:34:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 18:34:20 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1292870060.43.0.896300952334.issue10740@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also Issue 8145.  It would be nice if someone could sort all this out, but I'm not knowledgeable enough to do so.

For this patch, it would be a significant change it behaviour.  Therefore it would have to be a new feature controlled by a flag of some sort (which is part of the reason for the reference to issue 8145).

----------
nosy: +ghaering, r.david.murray
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:40:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Dec 2010 18:40:58 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <4D0FA0EF.9040002@scottdial.com>
Message-ID: <1292870454.3737.61.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The problem is to detect that stderr file descriptor changes (eg. closed, 
> > duplicated, reopened, etc.). I don't think that it's possible to detect such 
> > changes (with a portable function).
> 
> When I said that, I hadn't fully investigated the intricacies of the io
> types. I was unaware that you could assign to "sys.stderr.buffer.raw"
> and change out the target fd. I assumed a BufferedWriter could not have
> the target stream changed out from beneath it.

AFAICT, this is not deliberate (not documented, and not tested for). It
should probably be fixed, actually, because there's no code that I know
of that ensures it does something meaningful.

----------
title: Display Python backtrace on SIGSEGV,	SIGFPE and fatal error -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Dec 20 19:52:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 20 Dec 2010 18:52:10 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1292871130.02.0.338444884993.issue10557@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Mon Dec 20 20:20:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 19:20:24 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292872824.79.0.558611632046.issue10715@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +IO
nosy: +eric.araujo
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Mon Dec 20 20:25:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 19:25:08 +0000
Subject: [issue10728] argparse.ArgumentParser.print_help uses sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292873108.25.0.578150391343.issue10728@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alright, I didn?t know you were doing mass merges.  I personally prefer to leave reports open until backported, now I?ll know your habits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10728>
_______________________________________

From report at bugs.python.org  Mon Dec 20 20:27:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 19:27:07 +0000
Subject: [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1292873227.4.0.102987540407.issue8145@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17940/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8145>
_______________________________________

From report at bugs.python.org  Mon Dec 20 20:30:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 19:30:25 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1292873425.27.0.338955467523.issue10730@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on adding SVG types in 3.2 or 3.3.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Mon Dec 20 20:50:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 20 Dec 2010 19:50:27 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292874627.24.0.146076452418.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue10254a.diff, adds the OP's cases to test_unicodedata and changes the code as I suggested in msg124173 because ISTM that comb >= comb1 matches the pr-29 definition:

"""
D2'. In any character sequence beginning with a starter S, a character C is blocked from S if and only if there is some character B between S and C, and either B is a starter or it has the same or higher combining class as C.
""" http://www.unicode.org/review/pr-29.html

Unfortunately, all tests pass with either comb >= comb1 or comb == comb1, so before I commit, I would like to figure out the test case that would properly exercise this code.

----------
Added file: http://bugs.python.org/file20120/issue10254a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Mon Dec 20 22:02:53 2010
From: report at bugs.python.org (alesko)
Date: Mon, 20 Dec 2010 21:02:53 +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: <1292878973.35.0.174969154001.issue3871@psf.upfronthosting.co.za>


Changes by alesko <askondro at gmail.com>:


----------
nosy: +alesko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Dec 20 22:33:42 2010
From: report at bugs.python.org (flashk)
Date: Mon, 20 Dec 2010 21:33:42 +0000
Subject: [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

The 'readonly' attribute is not explicitly described, even though it is used in the sample code for the memoryview type.

I've attached a patch that adds a description of the 'readonly' attribute.

----------
assignee: docs at python
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 124403
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: memoryview.readonly attribute is not documented
versions: Python 2.7
Added file: http://bugs.python.org/file20121/stdtypes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10742>
_______________________________________

From report at bugs.python.org  Mon Dec 20 22:36:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 21:36:10 +0000
Subject: [issue1243654] Faster output if message already has a boundary
Message-ID: <1292880970.51.0.979613850987.issue1243654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Turns out there's a bug in my version of the patch, and no test in the email test suite traversed that code path.

Attached patch fixes this; I'll commit and backport after trunk unfreezes.  Note that the backport contains a second bug (calls self._make_boundary when it should be just _make_boundary)

----------
status: closed -> open
Added file: http://bugs.python.org/file20122/boundar_fix_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1243654>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:06:43 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 20 Dec 2010 22:06:43 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

>From http://code.google.com/p/virtualenv5/issues/detail?id=6 - it seems that the `sysconfig` module is looking for Makefile in wrong directory, while ideally it must be looking into the base Python install.

>> import sysconfig; sysconfig.get_paths('purelib')
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 332, in _init_posix
    _parse_makefile(makefile, vars)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: '/tmp/e/lib/python3.2/config-3.2m/Makefile'

----------
assignee: tarek
components: Distutils, Macintosh
messages: 124405
nosy: eric.araujo, srid, tarek
priority: normal
severity: normal
status: open
title: 3.2's sysconfig doesn't work with virtualenv
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:06:48 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 20 Dec 2010 22:06:48 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

Ctypes arrays have invalid buffer interface information (on Python 3.1.2):

>>> import ctypes
>>> x = (ctypes.c_double*2)()
>>> y = memoryview(x)
>>> y.shape
(2,)
>>> y.format
'(2)<d'

This implies that the array contains 2 items, each consisting of 2 floats, which is incorrect -- the shape information is duplicated.

A suggested fix is attached.

(From http://projects.scipy.org/numpy/ticket/1699)

----------
assignee: theller
components: ctypes
files: 001-ctypes-fix-pep-3118-format-strings-for-arrays.patch
keywords: patch
messages: 124406
nosy: pv, theller
priority: normal
severity: normal
status: open
title: ctypes arrays have incorrect buffer information (PEP-3118)
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20123/001-ctypes-fix-pep-3118-format-strings-for-arrays.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10744>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:08:52 2010
From: report at bugs.python.org (Scott Urban)
Date: Mon, 20 Dec 2010 22:08:52 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1292882932.55.0.156857878793.issue10740@psf.upfronthosting.co.za>


Scott Urban <scott.urban at isilon.com> added the comment:

I find the way that the sqlite3 module handles transactions pretty
surprising in general, but I agree that someone who got used
to DDL not rolling back could in theory find this patch surprising.

We will apply this patch to our python build because having DDL
covered by a transactions is convenient for certain tasks. If anyone
can think of a problem with this simple patch, I'd like to hear it.

Thanks
Scott

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:11:54 2010
From: report at bugs.python.org (Chris Lasher)
Date: Mon, 20 Dec 2010 22:11:54 +0000
Subject: [issue10745] --user option,
	per user site-packages undocumented in Installing Python Modules
	document
In-Reply-To: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>
Message-ID: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>


New submission from Chris Lasher <chris.lasher at gmail.com>:

Python 2.6 saw the introduction of per user site-packages directory for easy installation of Python packages into a guaranteed location in which the user has appropriate permissions.

http://bugs.python.org/issue1799
http://www.python.org/dev/peps/pep-0370/
http://docs.python.org/whatsnew/2.6.html#pep-370-per-user-site-packages-directory

With it came a new option available in distutils-powered setup.py scripts, "--user". It has been a year since this feature was introduced, yet no documentation has appeared in the official Python Documentation other than in the "What's New" document. Specifically, this option should appear and be documented in the "Installing Python Modules" document.

http://docs.python.org/install/

It would be very helpful if the documentation described the advantages of using this option over "--home" and "--prefix".

I am not the first user to notice this gap in the documentation, e.g.,

http://www.devx.com/opensource/Article/42353/1763

however, I couldn't find any bugs open for this issue so I have created this new one.

----------
assignee: tarek
components: Distutils, Documentation
messages: 124408
nosy: eric.araujo, gotgenes, tarek
priority: normal
severity: normal
status: open
title: --user option, per user site-packages undocumented in Installing Python Modules document
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/issue10745>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:13:25 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 20 Dec 2010 22:13:25 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1292883205.48.0.574760510781.issue10087@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

The problem is in the following line...

    return ''.join(v).encode(encoding, "xmlcharrefreplace")

The .encode(encoding, "xmlcharrefreplace") is returning a bytes object.

Here is the simplest change to resolve the problem.

    return str(''.join(v).encode(encoding, "xmlcharrefreplace"),
                encoding=encoding)

But maybe a different way to implement "xmlcharrefreplace" is what is needed.  Would it be better if it were a function or method in the xml (or html) module?

Just because it can be implemented as an encoding doesn't mean it should be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:18:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 22:18:54 +0000
Subject: [issue10745] setup.py install --user option undocumented
In-Reply-To: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>
Message-ID: <1292883534.4.0.215077742479.issue10745@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
components: +Distutils2 -Distutils
title: --user option, per user site-packages undocumented in Installing Python Modules document -> setup.py install --user option undocumented
versions: +3rd party -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/issue10745>
_______________________________________

From report at bugs.python.org  Mon Dec 20 23:38:32 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 20 Dec 2010 22:38:32 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1292884712.27.0.318943127633.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

Sorry in advance for the long winded response.

Ron, have you looked at my patch?

The underlying issue is that the semantics for print() between Python 1 and 3. print() does not accept a bytes type in Python 3. In Python 2 str was a "bytes" type and so print happily sent encoded strings to stdout. 

This presents an issue for both --type=html and the text version if an encoding is asked for. Just using print() will result in repr being called on the byte string and you get either an invalid HTML file or a text file with extra junk in it (same junk in both).

If you ask for an encoding, you are going to get bytes. Changing it back into a string to mask that effect does not actually fix things for you because once you do print() you are back to a default encoding and therefore more broken because you are not doing what the user asked for (which is a particular encoding).

In order for:
    return str(''.join(v).encode(encoding, "xmlcharrefreplace"),
                encoding=encoding)

to solve the issue, you would also need to take away the ability for the user to specify an encoding (at the command line and via the API). It's already a string, why make it a byte and then a string again? If you don't want to deal with encoding, then return a string and leave it up to the consumer of the API to handle the desired encoding (and the "xmlcharrefreplace", maybe with a note in the docs).

If you do want to deal with encoding (which I think we are stuck with), then solve the real issue by not using print() (see my patch).

I think the only reason that my patch was not accepted, and why this is still languishing is that I said I would provide tests and have not had time to do so. 

Please feel free to correct me if I am wrong about any of the above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Tue Dec 21 00:37:28 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 20 Dec 2010 23:37:28 +0000
Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes
In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>
Message-ID: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

Currently on Python 3.x:

>>> import ctypes
>>> memoryview(ctypes.c_long()).format
'<l'

This is invalid on 64-bit platforms: the above means 32-bit little-endian float. The '<' endian specification turns on the "standard size" mode (similarly as for the struct module), which makes type character have a platform-independent meaning.

Unfortunately, the struct module format syntax does *not* allow specifying native-size non-native-endian items. So just replacing '<' by '^' cannot be in general be done.

Suggested fix attached. It adds a converter function that maps the platform-dependent ctypes codes to struct module standard-size codes; handling c_long and c_bool specially.

    ***

After this patch (and the one in http://bugs.python.org/issue10744 ):

>>> import numpy as np
>>> from ctypes import *
>>> class Point(Structure):
...     _fields_ = [("x", c_long), ("y", c_long)]
... 
>>> class StructWithArrays(Structure):
...     _fields_ = [("x", c_long * 3 * 2), ("y", Point * 4)]
... 
>>> x = StructWithArrays()
>>> y = np.asarray(x)
>>> y.dtype
dtype([('x', '<i8', (2, 3)), ('y', [('x', '<i8'), ('y', '<i8')], (4,))])
>>> y['x'] = [[1,2,3],[4,5,6]]
>>> y['y']['x'] = np.arange(4) + 10
>>> y['y']['y'] = np.arange(4) + 20
>>> x.x[0][0]
1
>>> x.x[0][1]
2
>>> x.x[0][2]
3
>>> x.y[0].x
10
>>> x.y[1].x
11
>>> x.y[0].y
20
>>> x.y[1].y
21

----------
files: 001-ctypes-fix-pep-3118-type-codes-for-c-long-and-c-bool.patch
keywords: patch
messages: 124411
nosy: pv
priority: normal
severity: normal
status: open
title: ctypes c_long & c_bool have incorrect PEP-3118 type codes
Added file: http://bugs.python.org/file20124/001-ctypes-fix-pep-3118-type-codes-for-c-long-and-c-bool.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10746>
_______________________________________

From report at bugs.python.org  Tue Dec 21 00:37:52 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 20 Dec 2010 23:37:52 +0000
Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes
In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>
Message-ID: <1292888272.42.0.110809654221.issue10746@psf.upfronthosting.co.za>


Changes by Pauli Virtanen <pav at iki.fi>:


----------
assignee:  -> theller
components: +ctypes
nosy: +theller
type:  -> behavior
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10746>
_______________________________________

From report at bugs.python.org  Tue Dec 21 00:58:02 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Dec 2010 23:58:02 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292889482.31.0.0829181535183.issue10743@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That does seem to be a regression since distutils.sysconfig works correctly in a virtualenv:

$ python3.2 -c 'import distutils.sysconfig;print(distutils.sysconfig.get_makefile_filename())'
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/Makefile
$ python3.2 -c 'import sysconfig;print(sysconfig.get_makefile_filename())'
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/Makefile

but in a virtualenv:

$ source t/bin/activate
$ python3.2 -c 'import distutils.sysconfig;print(distutils.sysconfig.get_makefile_filename())'
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/Makefile
$ python3.2 -c 'import sysconfig;print(sysconfig.get_makefile_filename())'
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 332, in _init_posix
    _parse_makefile(makefile, vars)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: '/Users/nad/t/lib/python3.2/config-3.2m/Makefile'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 322, in get_makefile_filename
    return os.path.join(get_path('stdlib'),
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 451, in get_path
    return get_paths(scheme, vars, expand)[name]
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 442, in get_paths
    return _expand_vars(scheme, vars)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 168, in _expand_vars
    _extend_dict(vars, get_config_vars())
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 487, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", line 337, in _init_posix
    raise IOError(msg)


BTW, your example will fail in any case since get_paths takes a scheme name; "purelib" is a path name.

----------
nosy: +barry, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Tue Dec 21 00:59:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Dec 2010 23:59:55 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292889595.9.0.20204133471.issue10743@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Setting to deferred blocker for 3.2 release manager evaluation.

----------
nosy: +georg.brandl
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Tue Dec 21 01:10:59 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 21 Dec 2010 00:10:59 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1292890259.28.0.567432833413.issue10740@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Tue Dec 21 03:06:16 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 21 Dec 2010 02:06:16 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1292897176.03.0.354577110117.issue10087@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Oops.  You're right.  

I miss understood how the encode method works in this particular case. ;-/

I agree with your comments as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Tue Dec 21 04:36:44 2010
From: report at bugs.python.org (Phillip M. Feldman)
Date: Tue, 21 Dec 2010 03:36:44 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292872824.82.0.35829376013.issue10715@psf.upfronthosting.co.za>
Message-ID: <AANLkTik4CxPfLs+5qN6UwS=dnCfC6BdGGKSLZffRQ8wX@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

I eventually determined that a call to `subprocess.Popen` was responsible
for the message, but could have determined this much more quickly if the
message had included the name of the file that could not be opened
(executed).

Phillip

On Mon, Dec 20, 2010 at 11:20 AM, ??ric Araujo <report at bugs.python.org>wrote:

>
> Changes by ??ric Araujo <merwok at netwok.org>:
>
>
> ----------
> components: +IO
> nosy: +eric.araujo
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10715>
> _______________________________________
>

----------
nosy: +Phillip.M.Feldman at gmail.com
Added file: http://bugs.python.org/file20125/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________
-------------- next part --------------
I eventually determined that a call to `subprocess.Popen` was responsible for the message, but could have determined this much more quickly if the message had included the name of the file that could not be opened (executed).<br>
<br>Phillip<br><br><div class="gmail_quote">On Mon, Dec 20, 2010 at 11:20 AM, ??ric Araujo <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;">
<br>
Changes by ??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt;:<br>
<br>
<br>
----------<br>
components: +IO<br>
nosy: +eric.araujo<br>
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6<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/issue10715" target="_blank">http://bugs.python.org/issue10715</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Dec 21 05:30:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Dec 2010 04:30:02 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292905802.86.0.578664942077.issue10715@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20125/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 06:05:41 2010
From: report at bugs.python.org (Phillip M. Feldman)
Date: Tue, 21 Dec 2010 05:05:41 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292905802.92.0.411517223614.issue10715@psf.upfronthosting.co.za>
Message-ID: <AANLkTik9Dmmn5OS30Ov+K2My3i7SiSjZsE0spWwVJbGg@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

Why was this removed?

On Mon, Dec 20, 2010 at 8:30 PM, Alexander Belopolsky <
report at bugs.python.org> wrote:

>
> Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:
>
>
> Removed file: http://bugs.python.org/file20125/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10715>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20126/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________
-------------- next part --------------
Why was this removed?<br><br><div class="gmail_quote">On Mon, Dec 20, 2010 at 8:30 PM, Alexander Belopolsky <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;">
<br>
Changes by Alexander Belopolsky &lt;<a href="mailto:belopolsky at users.sourceforge.net">belopolsky at users.sourceforge.net</a>&gt;:<br>
<br>
<br>
Removed file: <a href="http://bugs.python.org/file20125/unnamed" target="_blank">http://bugs.python.org/file20125/unnamed</a><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/issue10715" target="_blank">http://bugs.python.org/issue10715</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Dec 21 06:11:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Dec 2010 05:11:39 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1292874627.24.0.146076452418.issue10254@psf.upfronthosting.co.za>
Message-ID: <AANLkTimu5rbO2C4J57WtBnkWn0UEgCcVkQLiJSQn=jAV@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Dec 20, 2010 at 2:50 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Unfortunately, all tests pass with either comb >= comb1 or comb == comb1, so before
> I commit, I would like to figure out the test case that would properly exercise this code.
>

After some more thought, I've realized that the comb > comb1 case is
impossible if comb1 != 0 (due to canonical reordering step) and if
comb1 == 0, the comb1 to comb comparison is not reached.  In other
words, it does not matter whether comparison is done as Martin
suggested in msg120018 or as it is done in the latest patch.  The fact
that comb > comb1 case is impossible if comb1 != 0 is actually
mentioned in PR 29 itself.  See Table 1: Differences at
http://www.unicode.org/review/pr-29.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:12:19 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 21 Dec 2010 08:12:19 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292919139.41.0.57145773766.issue10694@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi KevinH, sorry if I gave the wrong impression that you must submit a patch before anyone will look at the bug. I thought you wanted to provide a patch for this. If you only want to report a bug that is ok, thanks for that.

I have confirmed your bug on the py3k branch. Attached is a patch that adds a test case to test_zipfile.py (as requested by others) and ports Kevin's patch to py3k. I have confirmed that his patch works: without it the test fails, and with it the test passes. Note: You have to create a file "README.zip" in the Lib/test directory, because svn diff cannot display added files.

----------
Added file: http://bugs.python.org/file20127/Issue10694.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:14:17 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 21 Dec 2010 08:14:17 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292919257.03.0.190615829193.issue10694@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Sorry, forgot to add: README.zip should have a \r\n at the end. Actually I just zipped up README, ran echo "\r\n" >> README.zip and put it in Lib/test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:36:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 08:36:44 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292920604.31.0.764239089878.issue10715@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file20126/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:37:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 08:37:30 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292920650.66.0.765256591122.issue10715@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Because you're sending email as HTML, the message shows up both as plain text and as an attachment. It's the attachments that are being removed. If you could, please stop sending HTML email.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:40:10 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 08:40:10 +0000
Subject: [issue10715] uninformative error message
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292920810.18.0.139346955683.issue10715@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's a code snippet that shows the problem:

>>> import subprocess
>>> subprocess.Popen(['foo'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/subprocess.py", line 593, in __init__
    errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1079, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:41:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 08:41:24 +0000
Subject: [issue10715] Command name missing from exception in subprocess.Popen
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292920884.65.0.856019251143.issue10715@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
title: uninformative error message -> Command name missing from exception in subprocess.Popen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:41:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 08:41:47 +0000
Subject: [issue10715] Command name missing from exception in subprocess.Popen
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292920907.89.0.808619636935.issue10715@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:43:37 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Tue, 21 Dec 2010 08:43:37 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292921017.58.0.28989660986.issue9584@psf.upfronthosting.co.za>


Changes by Mathieu Bridon <bochecha at fedoraproject.org>:


Removed file: http://bugs.python.org/file19451/0001-Curly-brace-expansion-in-glob.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:44:17 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Tue, 21 Dec 2010 08:44:17 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292921057.26.0.430640898253.issue9584@psf.upfronthosting.co.za>


Mathieu Bridon <bochecha at fedoraproject.org> added the comment:

Same patch, but rebased to the current trunk so it still applies.

----------
Added file: http://bugs.python.org/file20128/0001-Curly-brace-expansion-in-glob.patch.old

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:44:57 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Tue, 21 Dec 2010 08:44:57 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292921097.04.0.539913483069.issue9584@psf.upfronthosting.co.za>


Changes by Mathieu Bridon <bochecha at fedoraproject.org>:


Removed file: http://bugs.python.org/file20128/0001-Curly-brace-expansion-in-glob.patch.old

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 09:45:38 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Tue, 21 Dec 2010 08:45:38 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292921138.34.0.199512367687.issue9584@psf.upfronthosting.co.za>


Mathieu Bridon <bochecha at fedoraproject.org> added the comment:

This is the right patch, sorry for all the mail spam. :-/

----------
Added file: http://bugs.python.org/file20129/0001-Curly-brace-expansion-in-glob.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 10:51:57 2010
From: report at bugs.python.org (sean216)
Date: Tue, 21 Dec 2010 09:51:57 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292925117.76.0.641904414803.issue10724@psf.upfronthosting.co.za>


sean216 <taoyuan-216 at 163.com> added the comment:

> Note that in your sample capture, I don't see any invalid sequence/ack number.

please check telnet_unnormal RST.pcap in No. 1600-1602,the 1602 RST meseage is the invalid sequence/ack number 172.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Tue Dec 21 11:36:28 2010
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 21 Dec 2010 10:36:28 +0000
Subject: [issue9355] argparse add_mutually_exclusive_group more than once has
	incorrectly formatted help
In-Reply-To: <1279895728.08.0.860550350605.issue9355@psf.upfronthosting.co.za>
Message-ID: <1292927788.8.0.727329175982.issue9355@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9355>
_______________________________________

From report at bugs.python.org  Tue Dec 21 11:53:24 2010
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 21 Dec 2010 10:53:24 +0000
Subject: [issue10680] argparse: titles and add_mutually_exclusive_group don't
	mix (even with workaround)
In-Reply-To: <1292083248.97.0.928495782189.issue10680@psf.upfronthosting.co.za>
Message-ID: <1292928804.09.0.962210823566.issue10680@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yep, I believe that fix should work. Now to find the time to write some tests...

----------
nosy: +bethard
stage:  -> unit test needed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10680>
_______________________________________

From report at bugs.python.org  Tue Dec 21 12:24:21 2010
From: report at bugs.python.org (OBATA Akio)
Date: Tue, 21 Dec 2010 11:24:21 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1292930661.44.0.572570928021.issue10475@psf.upfronthosting.co.za>


OBATA Akio <obata at lins.jp> added the comment:

This patch is also required for DragonFly, or libpython will not linked against libpthread and broken library.

----------
nosy: +obache

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10475>
_______________________________________

From report at bugs.python.org  Tue Dec 21 12:53:59 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Dec 2010 11:53:59 +0000
Subject: [issue10747] Include version info in Windows shortcuts
In-Reply-To: <1292932439.68.0.958376446451.issue10747@psf.upfronthosting.co.za>
Message-ID: <1292932439.68.0.958376446451.issue10747@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

This issue is to propose specific wording to Martin for inclusion of version details in the Windows shortcuts. This is to make the shortcuts easier to use when the hierarchical menu information is lost for any reason (e.g frequently used program list, searching the start menu, copied to desktop).

Shortcuts currently installed:
- Python (command line)
- Python Manuals
- Module Docs
- IDLE (Python GUI)
- Uninstall Python

Initial proposal for 32 bit builds:
- Python 3.2 (command line - 32 bit)
- Python 3.2 Manuals
- Python 3.2 Docs Server (pydoc - 32 bit)
- IDLE (Python 3.2 GUI - 32 bit)
- Uninstall Python 3.2 (32 bit)

Initial proposal for 64 bit builds:
- Python 3.2 (command line - 64 bit)
- Python 3.2 Manuals
- Python 3.2 Docs Server (pydoc - 64 bit)
- IDLE (Python 3.2 GUI - 64 bit)
- Uninstall Python 3.2 (64 bit)

Any feedback/alternate suggestions/bikeshedding on the python-dev thread, please ;)

----------
messages: 124427
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Include version info in Windows shortcuts
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10747>
_______________________________________

From report at bugs.python.org  Tue Dec 21 13:20:41 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 12:20:41 +0000
Subject: [issue10715] Command name missing from exception in subprocess.Popen
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292934041.62.0.908851586638.issue10715@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This has already been fixed in 3.2:

Python 3.2b2 (py3k:87413, Dec 21 2010, 07:09:13) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['foo'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/python/py3k/Lib/subprocess.py", line 708, in __init__
    restore_signals, start_new_session)
  File "/root/python/py3k/Lib/subprocess.py", line 1323, in _execute_child
    raise child_exception_type(errno_num, err_msg)
OSError: [Errno 2] No such file or directory: 'foo'

It looks like it was changed by Benjamin in r86595. Not sure why that wasn't backported.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 13:24:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 21 Dec 2010 12:24:24 +0000
Subject: [issue10715] Command name missing from exception in subprocess.Popen
In-Reply-To: <1292480858.2.0.327042379298.issue10715@psf.upfronthosting.co.za>
Message-ID: <1292934264.4.0.185234500292.issue10715@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

That change was just a tweak. The real change was in r86593. It references issue 4925, of which this is a duplicate. I'm closing this, if you want to follow the issue add yourself to 4925.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Improve error message of subprocess when cannot open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10715>
_______________________________________

From report at bugs.python.org  Tue Dec 21 13:43:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 21 Dec 2010 12:43:05 +0000
Subject: [issue10242] unittest's assertItemsEqual() method makes too many
	assumptions about its input
In-Reply-To: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>
Message-ID: <1292935385.43.0.38468922501.issue10242@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This is committed to 2.7 and 3.2 (using the old name assertItemsEqual in 2.7). As we're well into the beta cycle I don't think we can change the name in 3.2.

The current failure output is very nice for comparing sequences like [1, 2, 3] vs [1, 2, 4]:

AssertionError: Expected, but missing:
    [4]
Unexpected, but present:
    [3]


It is less good for sequences like [2, 2] vs [2, 2, 2]:

AssertionError: Expected, but missing:
    [2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Tue Dec 21 14:39:26 2010
From: report at bugs.python.org (Mher Movsisyan)
Date: Tue, 21 Dec 2010 13:39:26 +0000
Subject: [issue5879] multiprocessing - example "pool of http servers " fails
	on windows "socket has no attribute fromfd"
In-Reply-To: <1241019482.48.0.575158847578.issue5879@psf.upfronthosting.co.za>
Message-ID: <1292938766.16.0.950897075497.issue5879@psf.upfronthosting.co.za>


Mher Movsisyan <mher.movsisyan at gmail.com> added the comment:

py3k does support socket.fromfd on Windows (#1378)

----------
nosy: +mher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5879>
_______________________________________

From report at bugs.python.org  Tue Dec 21 15:19:13 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 21 Dec 2010 14:19:13 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292941153.65.0.358253397935.issue4761@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch that adds:
faccessat, fchmodat, fchownat, fstatat, futimesat, linkat, mkdirat, mknodat, openat, readlinkat, renameat, symlinkat, unlinkat, utimensat and mkfifoat.

Each function has documentation and a unit test and is conditionally included only if the functions exist using autoconf testing. Most of the code for the functions and unit tests was taken from the corresponding non-at versions.

Tested on Linux 2.6.35 and FreeBSD 8.1 (although FreeBSD 8.1 does not have utimensat).

This should then allow a patch for #4489 to be created.

----------
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20130/i4761.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Tue Dec 21 17:30:28 2010
From: report at bugs.python.org (Ian Stevens)
Date: Tue, 21 Dec 2010 16:30:28 +0000
Subject: [issue10748] zipfile does not write empty ZIP structure if close()
	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>


New submission from Ian Stevens <iancstevens at gmail.com>:

The zipfile documentation (http://docs.python.org/library/zipfile.html) states:

"If the file is created with mode 'a' or 'w' and then close()d without adding any files to the archive, the appropriate ZIP structures for an empty archive will be written to the file."

This is not the case, eg.::

    >>> from StringIO import StringIO
    >>> import zipfile
    >>> s = StringIO()
    >>> z = zipfile.ZipFile(s, 'w')
    >>> z.close()
    >>> s.len
    0

The code for zipfile (http://svn.python.org/projects/python/trunk/Lib/zipfile.py) does not support the documentation either. The ending records are written only if ZipFile._didModify is True, and that attribute is only set to True if writestr() or write() are called.

Either the code should be fixed to support writing the ending records on an empty zip, or the documentation should be changed to reflect the existing behaviour.

Test case (for Lib/test/test_zipfile)::

    def test_close_empty_zip_creates_valid_zip(self):
        # Test that close() called on a ZipFile without write creates a valid ZIP.
        zf = zipfile.ZipFile(TESTFN, "w")
        zf.close()
        chk = zipfile.is_zipfile(TESTFN)
        self.assertTrue(chk)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 124433
nosy: Ian.Stevens, docs at python
priority: normal
severity: normal
status: open
title: zipfile does not write empty ZIP structure if close() called after __init__() as doc suggests
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10748>
_______________________________________

From report at bugs.python.org  Tue Dec 21 17:47:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 16:47:17 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292950037.31.0.941242848289.issue10724@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Regardless, Python doesn't generate the tcp/ip sequence numbers, the OS socket library does, so this is not a bug in Python.  If you follow the code link I posted you will see that, other than Python internal bookkeeping, the only thing socket.close does is to call the platform socket close method.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Tue Dec 21 17:48:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 16:48:20 +0000
Subject: [issue10748] zipfile does not write empty ZIP structure if close()
	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292950100.51.0.239619952148.issue10748@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This has been fixed in Python 2.7.1 (which the online docs refer to).  I assume that you're using 2.6 or an earlier version.

As for the code in SVN, the "trunk" is currently not in use; development happens in the "release27-maint", "release31-maint" and "py3k" branches (the latter being the actual trunk of development).  This irritation will go away soon once we have migrated to Hg.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10748>
_______________________________________

From report at bugs.python.org  Tue Dec 21 17:59:26 2010
From: report at bugs.python.org (Ian Stevens)
Date: Tue, 21 Dec 2010 16:59:26 +0000
Subject: [issue10748] zipfile does not write empty ZIP structure if close()
	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292950766.37.0.988710704924.issue10748@psf.upfronthosting.co.za>


Ian Stevens <iancstevens at gmail.com> added the comment:

Yes, I'm using 2.6. 

If this is not the expected behaviour in 2.6, the doc should reflect that with a "New in version 2.7" note.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10748>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:00:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 21 Dec 2010 17:00:37 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1292950837.2.0.847454333341.issue10733@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with Martin that this is a tricky one. 

The file is problematic because it is invalid XML[1], however Apple's tools are perfectly happy to proces the file and as Mitchell notes plistlib exists to interoperate with Apple's plist files.

I'm therefore reopening the issue, but with a low priority. It is unlikely that I'll work on this in the near future though. 

Replacing all control characters by entities before trying to parse the Plist XML would likely be the best way forward. A patch (including testcases) would definitely be appreciated.

BTW. I've checked that Apple's Cocoa libraries will read the file, this is not just a bug in the xml1 output formatter of plutil.

Using PyObjC:
>>> from Foundation import NSDictionary
>>> d = NSDictionary.dictionaryWithContentsOfFile_('com.apple.Terminal.plist')



[1] It is invalid XML because it contains control characters which are invalid according to the XML specification (<http://www.w3.org/TR/2000/REC-xml-20001006#NT-Char>).

----------
priority: normal -> low
stage: committed/rejected -> unit test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:49:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 17:49:05 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1292953745.14.0.759575181951.issue10475@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does it work properly if CC and CXX are not defined by the user?
(probably a na?ve question, sorry)

----------
nosy: +pitrou
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10475>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:50:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 17:50:47 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292953847.29.0.992831085877.issue10743@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed it should probably be a release blocker. I guess it has to do with (not) following symlinks, right?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:51:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 17:51:10 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292953870.16.0.425139985629.issue4761@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: unit test needed -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:51:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 17:51:36 +0000
Subject: [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1292953896.44.0.0786786852955.issue10742@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10742>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:58:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 17:58:21 +0000
Subject: [issue10748] zipfile does not write empty ZIP structure if close()
	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292954301.5.0.618867790923.issue10748@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

We usually don't do this for bugfixes, but here it makes sense I guess. r87414.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10748>
_______________________________________

From report at bugs.python.org  Tue Dec 21 18:59:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 17:59:27 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292954367.55.0.124554320746.issue10743@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, let's make this one.  Tarek to the rescue!

----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:06:45 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 21 Dec 2010 18:06:45 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1292954805.49.0.427958414999.issue10743@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Will do tonight

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:25:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 18:25:45 +0000
Subject: [issue1243654] Faster output if message already has a boundary
Message-ID: <1292955945.79.0.773427458322.issue1243654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed test and fix in r87415, r87416, r87417.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1243654>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:28:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:28:46 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292956126.54.0.53026258927.issue4761@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. A couple of comments:
- the C code is misindented in some places (using 8 spaces rather than 4)
- you should use support.unlink consistently in the tests (rather than sometimes os.unlink or posix.unlink)
- when cleaning up in tests (through unlink() or rmdir()), it's better to use finally clauses so that cleaning up gets done even on error; or, alternatively, to use self.addCleanup() (see http://docs.python.org/dev/library/unittest.html#unittest.TestCase.addCleanup)

(I haven't looked at the C code in detail since you say it's mostly copy/paste from existing code)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:31:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 18:31:24 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1292956284.86.0.161432860538.issue10744@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/issue10744>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:36:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:36:07 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292806293.27.0.64653489151.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292956561.3720.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Adding a warning sounds like a good idea.  Is it reasonable to include
> a recommended cross-platform approach in the platform doc, like either
> the sys.maxsize test or the struct.calsize("P") test (which is used as
> a default fallback in platform.architecture)?

Yes.

>   Are there any currently supported platforms where either of those
> wouldn't work?

No. I think even on fringe platforms it is unlikely for size_t to not
reflect the native pointer width (although it is theoretically
possible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:38:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:38:59 +0000
Subject: [issue10749] lots of warnings when generating logging docs
In-Reply-To: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>
Message-ID: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

"make html" in the Doc directory and then:

[...]
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:507: WARNING: duplicate object description of logging.logging.Formatter.__init__, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst, use :noindex: for one of them
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:733: WARNING: duplicate label library-config, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:849: WARNING: duplicate label useful-handlers, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:834: WARNING: duplicate label custom-levels, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:944: WARNING: duplicate label logging-exceptions, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:969: WARNING: duplicate label arbitrary-object-messages, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging.rst:460: WARNING: duplicate label handler-basic, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:596: WARNING: duplicate label filters-contextual, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:149: WARNING: duplicate label multiple-destinations, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:333: WARNING: duplicate label network-logging, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:470: WARNING: duplicate label context-info, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:872: WARNING: duplicate label zeromq-handlers, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
/home/antoine/py3k/__svn__/Doc/howto/logging-cookbook.rst:670: WARNING: duplicate label multiple-processes, other instance in /home/antoine/py3k/__svn__/Doc/library/logging.rst
[...]

----------
assignee: vinay.sajip
components: Documentation, Library (Lib)
messages: 124446
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: lots of warnings when generating logging docs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10749>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:39:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:39:18 +0000
Subject: [issue10749] lots of warnings when generating logging docs
In-Reply-To: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>
Message-ID: <1292956758.43.0.213002446807.issue10749@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10749>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:46:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 18:46:14 +0000
Subject: [issue10749] lots of warnings when generating logging docs
In-Reply-To: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>
Message-ID: <1292957174.33.0.502311992815.issue10749@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Will vanish after a full rebuild; the duplicate detection is a bit buggy in Sphinx when the documents are read in the wrong order.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10749>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:46:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 18:46:51 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1292957211.49.0.61278828439.issue10744@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10744>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:50:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:50:44 +0000
Subject: [issue10735] platform.architecture() gives misleading results for OS
	X multi-architecture executables
In-Reply-To: <1292740109.65.0.867895032728.issue10735@psf.upfronthosting.co.za>
Message-ID: <1292957444.72.0.992954862125.issue10735@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm committing a doc update in r87421 with a suggestion to use sys.maxsize. I'll let Marc-Andr? decide how to deal with the rest of the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________

From report at bugs.python.org  Tue Dec 21 19:54:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 18:54:56 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292957696.88.0.208447236284.issue10694@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

"High" is not near high enough to get noticed before the release :)

----------
nosy: +georg.brandl
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 21 20:20:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 19:20:51 +0000
Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes
In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>
Message-ID: <1292959251.75.0.754120708691.issue10746@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10746>
_______________________________________

From report at bugs.python.org  Tue Dec 21 20:24:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Dec 2010 19:24:03 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1292959443.04.0.220017242258.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In the new patch, issue10254b.diff, I've added a test that would crash unpatched code:

>>> unicodedata.normalize('NFC', 'C?C?C?C?C?C?C?C?C?C?C?C?C?C?C?C?C?C?C?C??')
Segmentation fault

Martin, I still feel uneasy about the fixed size of the skipped buffer.  It is not obvious that skipped combining characters always get removed from the buffer before the next starter is processed.

I would really like another pair of eyes to look at this code before it goes in especially to 2.6.

Victor,

IIRC, you did some stress testing on random data.  I wonder if you could test this code after tightening the assert to cskipped < 4.  (The current theory is that this should be enough.)

----------
Added file: http://bugs.python.org/file20131/issue10254b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Tue Dec 21 20:25:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 19:25:35 +0000
Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes
In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>
Message-ID: <1292959535.29.0.183805323837.issue10746@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10746>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:21:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 20:21:59 +0000
Subject: [issue10750] "raw" attribute of buffered IO objects is assignable
In-Reply-To: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>
Message-ID: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This really looks backwards:

>>> f = open("LICENSE", "rb")
>>> f.name = "bar"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute 'name' of '_io.BufferedReader' objects is not writable
>>> f.raw = None
__main__:1: ResourceWarning: unclosed file <_io.FileIO name='LICENSE' mode='rb'>
>>>

----------
components: IO, Library (Lib)
messages: 124451
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "raw" attribute of buffered IO objects is assignable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10750>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:35:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 20:35:24 +0000
Subject: [issue10750] "raw" attribute of buffered IO objects is assignable
In-Reply-To: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>
Message-ID: <1292963724.26.0.229535398035.issue10750@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20132/io_roattrs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10750>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:36:27 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 21 Dec 2010 20:36:27 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292963787.48.0.193587360297.issue4761@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is an updated patch which:
- fixes badly indented C code
- uses support.unlink consistently
- cleans up tests better using finally

----------
Added file: http://bugs.python.org/file20133/i4761_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:36:31 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Dec 2010 20:36:31 +0000
Subject: [issue10750] "raw" attribute of buffered IO objects is assignable
In-Reply-To: <1292963724.26.0.229535398035.issue10750@psf.upfronthosting.co.za>
Message-ID: <AANLkTikScEKSc3iqkh2E48yH7g=OAq=Bfz3vgV5_-vqX@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/12/21 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Here is a patch.

I assume you can put test_readonly_attributes in CommonBufferTests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10750>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:37:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 20:37:49 +0000
Subject: [issue10750] "raw" attribute of buffered IO objects is assignable
In-Reply-To: <AANLkTikScEKSc3iqkh2E48yH7g=OAq=Bfz3vgV5_-vqX@mail.gmail.com>
Message-ID: <1292963863.3720.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 21 d?cembre 2010 ? 20:36 +0000, Benjamin Peterson a ?crit :
> Benjamin Peterson <benjamin at python.org> added the comment:
> 
> 2010/12/21 Antoine Pitrou <report at bugs.python.org>:
> >
> > Antoine Pitrou <pitrou at free.fr> added the comment:
> >
> > Here is a patch.
> 
> I assume you can put test_readonly_attributes in CommonBufferTests?

That's where it is :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10750>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:39:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Dec 2010 20:39:06 +0000
Subject: [issue10750] "raw" attribute of buffered IO objects is assignable
In-Reply-To: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>
Message-ID: <1292963946.44.0.0296069886717.issue10750@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Ah, I see. LGTM then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10750>
_______________________________________

From report at bugs.python.org  Tue Dec 21 21:40:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Dec 2010 20:40:41 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292964041.78.0.120107052625.issue4761@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The docs shouldn't use "[" to denote optional args. Rather, optional arguments can just be shown by their defaults.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Tue Dec 21 22:27:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 21:27:14 +0000
Subject: [issue10750] "raw" attribute of buffered IO objects is assignable
In-Reply-To: <1292962919.83.0.998422022844.issue10750@psf.upfronthosting.co.za>
Message-ID: <1292966834.57.0.152842187963.issue10750@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, committed in r87427 (3.2), r87428 (3.1) and r87429 (2.7).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10750>
_______________________________________

From report at bugs.python.org  Tue Dec 21 22:30:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 21:30:06 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292967006.33.0.813004109837.issue9584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the research and the updated patch.  Unfortunately as a feature request this is going to have to wait for 3.3 since we missed the pre-beta window.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 22:36:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 21:36:17 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1292967377.4.0.450149580001.issue4871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thinking about this some more, it seems like the chance that someone is using bytearray to pass a password to zipfile is vanishingly small, especially since in non-optimized mode setpassword would have rejected it.  So I think that this should go in.

----------
assignee:  -> r.david.murray
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Dec 21 22:42:29 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Tue, 21 Dec 2010 21:42:29 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292967749.04.0.651358166967.issue9584@psf.upfronthosting.co.za>


Mathieu Bridon <bochecha at fedoraproject.org> added the comment:

> Thanks for the research and the updated patch.  Unfortunately as
> a feature request this is going to have to wait for 3.3 since we
> missed the pre-beta window.

Ok.

This is my first patch to Python, so I'm not sure what I should do to get this in.

Is keeping the patch in sync with the trunk enough? Is there something else, like some more formal process to follow?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 22:47:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 21:47:13 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1292968033.6.0.483201202582.issue9584@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Nope, you've got it.

After the final release of Python 3.2, please post to the issue to remind us about it, and someone will commit the patch.  (For future Python releases we expect that the delays in our ability to commit feature patches will be much shorter, but this is the way it works right now.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Tue Dec 21 23:03:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 22:03:18 +0000
Subject: [issue4871] zipfile can't decrypt
In-Reply-To: <1231359985.6.0.664032853726.issue4871@psf.upfronthosting.co.za>
Message-ID: <1292968998.19.0.683815294722.issue4871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r87430 (with message word order change), backported to 3.1 in r87431.  Making the parallel change to 2.7 would be likely to break working code, IMO.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4871>
_______________________________________

From report at bugs.python.org  Tue Dec 21 23:08:40 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Tue, 21 Dec 2010 22:08:40 +0000
Subject: [issue9285] A decorator for cProfile and profile modules
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1292969320.48.0.913083724568.issue9285@psf.upfronthosting.co.za>


Lukas Lueg <lukas.lueg at gmail.com> added the comment:

+1

----------
nosy: +ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Tue Dec 21 23:45:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 22:45:06 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1292971506.51.0.831941745597.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Xuanji: thanks for taking a crack at the test.

Rather than adding another data file to the test directory, how about creating a zipfile using the zipfile module in the test, closing it, opening it as a file, writing the /r/n to it, and then opening it back up for read as a zipfile for the test.  That's more parallel to how the other zipfile tests work.

Given what we know I'd be inclined to accept Kevin's suggested fix, unless Alan speaks up against it.  In that case the test may as well check that the comment is what we expect, as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Tue Dec 21 23:46:16 2010
From: report at bugs.python.org (Alex Raitz)
Date: Tue, 21 Dec 2010 22:46:16 +0000
Subject: [issue10751] WSGIREF - REMOTE_USER and REMOTE-USER collision
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>


New submission from Alex Raitz <alex.raitz at gmail.com>:

Clients can overwrite 'REMOTE_USER' header variable value with an arbitrary 'Remote-User' value by specifying the later after the former.

This has tricky implications when a proxy server is being used, namely that if the proxy passes a re-written REMOTE_USER but also the user-supplied 'Remote-User', Python WSGI will actually store HTTP_REMOTE_USER as the value of the user-supplied 'Remote-User' header based on the order that the headers are processed. 

./python2.6/wsgiref/headers.py:

184         for k, v in _params.items():
185             if v is None:
186                 parts.append(k.replace('_', '-'))
187             else:
188                 parts.append(_formatparam(k.replace('_', '-'), v))

----------
components: Extension Modules
messages: 124466
nosy: Alex.Raitz
priority: normal
severity: normal
status: open
title: WSGIREF - REMOTE_USER and REMOTE-USER collision
type: security
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Tue Dec 21 23:54:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Dec 2010 22:54:49 +0000
Subject: [issue10751] WSGIREF - REMOTE_USER and REMOTE-USER collision
In-Reply-To: <1292971576.27.0.760159303747.issue10751@psf.upfronthosting.co.za>
Message-ID: <1292972089.6.0.959086990549.issue10751@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10751>
_______________________________________

From report at bugs.python.org  Wed Dec 22 00:09:42 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 21 Dec 2010 23:09:42 +0000
Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of
	os.popen
In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>
Message-ID: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I noticed that despite ActivePerl being installed, `os.popen(...).close()` returned 1 (see find_working_perl in build_ssl.py), while in actuality that command executed successfully with return code 0; I verified this by using the subprocess module.

Here's a patch:

--- python/PCbuild/build_ssl.py.orig
+++ python/PCbuild/build_ssl.py
@@ -45,11 +45,11 @@
 # Being a Perl dummy, the simplest way I can check is if the "Win32" package
 # is available.
 def find_working_perl(perls):
+    import subprocess
     for perl in perls:
-        fh = os.popen('"%s" -e "use Win32;"' % perl)
-        fh.read()
-        rc = fh.close()
-        if rc:
+        try:
+            subprocess.check_call('"%s" -e "use Win32;"' % perl, shell=True)
+        except subprocess.CalledProcessError:
             continue
         return perl
     print("Can not find a suitable PERL:")

----------
components: Build, Windows
messages: 124467
nosy: srid
priority: normal
severity: normal
status: open
title: build_ssl.py is relying on unreliable behaviour of os.popen
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10752>
_______________________________________

From report at bugs.python.org  Wed Dec 22 00:12:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 23:12:10 +0000
Subject: [issue10752] build_ssl.py is relying on unreliable behaviour of
	os.popen
In-Reply-To: <1292972982.57.0.365932571977.issue10752@psf.upfronthosting.co.za>
Message-ID: <1292973130.88.0.162137557702.issue10752@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ocean-city
nosy: +loewis, ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10752>
_______________________________________

From report at bugs.python.org  Wed Dec 22 00:40:26 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 21 Dec 2010 23:40:26 +0000
Subject: [issue10747] Include version info in Windows shortcuts
In-Reply-To: <1292932439.68.0.958376446451.issue10747@psf.upfronthosting.co.za>
Message-ID: <1292974826.23.0.665496115146.issue10747@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10747>
_______________________________________

From report at bugs.python.org  Wed Dec 22 00:42:28 2010
From: report at bugs.python.org (Timothy Gates)
Date: Tue, 21 Dec 2010 23:42:28 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>


New submission from Timothy Gates <tim.gates at gmail.com>:

Consider the URL making use of the RFC1808 param syntax...

http://www/path;cookie=1234

The entire section '/path;cookie=1234' is passed in as PATH_INFO and so under the request_uri implementation it will be quoted

> import wsgiref
> wsgiref.request_uri({'wsgi.url_scheme': 'http', 'HTTP_HOST': 'www', 'PATH_INFO': '/path;cookie=1234'})
'http://www/path%3Bcookie%3D1234'

----------
components: Library (Lib)
messages: 124468
nosy: Timothy.Gates
priority: normal
severity: normal
status: open
title: request_uri method of wsgiref module does not support RFC1808 params.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Wed Dec 22 01:20:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 00:20:24 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1292977224.32.0.350996757442.issue10753@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Presumably all that is needed is to add ';' to 'safe' in the call that encodes PATH_INFO?

----------
nosy: +orsenthil, pje, r.david.murray
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Wed Dec 22 01:20:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 00:20:30 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1292977230.48.0.502055681122.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I set LANG and LC_ALL to C and tried to import a module with a non-ASCII name:
    $ ./python -m ?chec??
    python: No module named '\udcc3\udca9chec\udce2\udc84\udca2\udce2\udc99\udca5'
Is that a good enough test?

I guess the ?__main__ changes? you?re talking about are the addition of single quotes around __main__ in some error messages; that was only for the sake of consistency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 01:29:15 2010
From: report at bugs.python.org (Nicolas Joly)
Date: Wed, 22 Dec 2010 00:29:15 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1292977755.19.0.0413197741761.issue10475@psf.upfronthosting.co.za>


Nicolas Joly <njoly at pasteur.fr> added the comment:

I do not tested it extensively, but seems so.

njoly at petaure [temp/python27]> ./python
Python 2.7.1+ (release27-maint:87432M, Dec 22 2010, 01:10:26) 
[GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] on netbsd5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version
'2.7.1+ (release27-maint:87432M, Dec 22 2010, 01:10:26) \n[GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)]'
>>> import os
>>> os.uname()
('NetBSD', 'petaure.lan', '5.99.41', 'NetBSD 5.99.41 (PETAURE) #7: Mon Dec 20 23:06:49 CET 2010  njoly at petaure.lan:/local/src/NetBSD/obj.amd64/sys/arch/amd64/compile/PETAURE', 'amd64')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10475>
_______________________________________

From report at bugs.python.org  Wed Dec 22 02:12:46 2010
From: report at bugs.python.org (sean216)
Date: Wed, 22 Dec 2010 01:12:46 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292980366.93.0.728177966784.issue10724@psf.upfronthosting.co.za>


Changes by sean216 <taoyuan-216 at 163.com>:


Removed file: http://bugs.python.org/file20091/normal RST and fin.pcap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Wed Dec 22 02:12:51 2010
From: report at bugs.python.org (sean216)
Date: Wed, 22 Dec 2010 01:12:51 +0000
Subject: [issue10724] socket.close close telnet with RST
In-Reply-To: <1292571637.97.0.111675378361.issue10724@psf.upfronthosting.co.za>
Message-ID: <1292980371.66.0.960172492314.issue10724@psf.upfronthosting.co.za>


Changes by sean216 <taoyuan-216 at 163.com>:


Removed file: http://bugs.python.org/file20090/telnet_unnormal RST.pcap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10724>
_______________________________________

From report at bugs.python.org  Wed Dec 22 02:13:41 2010
From: report at bugs.python.org (K Richard Pixley)
Date: Wed, 22 Dec 2010 01:13:41 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1292980421.23.0.630989920009.issue4489@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

How does "rm -rf" address this issue?  Or does it?

shutils.rmtree should probably do the same thing.

----------
nosy: +teamnoir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Dec 22 02:52:00 2010
From: report at bugs.python.org (Wang Yanjin)
Date: Wed, 22 Dec 2010 01:52:00 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>


New submission from Wang Yanjin <wyj1046 at gmail.com>:

There is a file named "?Torrent.lnk" in the folder.

Here is the code:

#encoding=utf-8

import os
for i in os.listdir('.'):
    print os.path.isfile(i), '\t', i
a = input()

and the output:


True    3.py
False   a???.txt
True    uTorrent.lnk
False   ?Torrent.lnk
False   ?Torrent1.lnk
False   ???.txt
False   ???.txt.lnk
True    ?????
True    ??.txt
True    ??.txt.lnk


the function just doesn't work with the character "?"

----------
components: Unicode, Windows
messages: 124473
nosy: wyj1046
priority: normal
severity: normal
status: open
title: os.path.isfile doesn't work with some greek characters
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:01:21 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 22 Dec 2010 02:01:21 +0000
Subject: [issue8275] callback function on win64 results in bad behavior. mem
	corruption?
In-Reply-To: <1270061625.47.0.601780173179.issue8275@psf.upfronthosting.co.za>
Message-ID: <1292983281.57.0.537023573763.issue8275@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Attaching a patch for the configuration changes mentioned in msg102544

----------
keywords: +patch
nosy: +srid
Added file: http://bugs.python.org/file20134/issue8275_win64_ctypes_no_optimization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8275>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:09:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 02:09:23 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292983763.38.0.258324313722.issue10754@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I am unable to reproduce this on any python from py3k trunk down to 2.6.6.  Can you provide a complete test program that demonstrates the failure?  (That is, it creates the file and then fails to detect it as a file with isfile.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:27:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 02:27:08 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292984828.13.0.98685962174.issue10754@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, yes, and it is likely to be important to know what OS you are on.  I tested on linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:29:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 02:29:21 +0000
Subject: [issue3405] Add support for the new data option supported by event
	generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1292984961.37.0.770181674635.issue3405@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review
type:  -> feature request
versions: +Python 3.3 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:39:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 02:39:04 +0000
Subject: [issue3500] unbound methods of different classes compare equal
In-Reply-To: <1217877214.51.0.0221142821046.issue3500@psf.upfronthosting.co.za>
Message-ID: <1292985544.68.0.7929517753.issue3500@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since 2.7 has been released and this behaviour could not be changed in a point release even if agreement that it was a good change was reached, and since it is meaningless in 3.x, I'm closing this issue.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3500>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:46:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 02:46:08 +0000
Subject: [issue4078] asyncore fixes are not backwards compatible
In-Reply-To: <1223489086.17.0.537265261375.issue4078@psf.upfronthosting.co.za>
Message-ID: <1292985968.81.0.122111231148.issue4078@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like Josiah just forgot to close this bug, so I'm closing it.

----------
nosy: +r.david.murray
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4078>
_______________________________________

From report at bugs.python.org  Wed Dec 22 03:52:29 2010
From: report at bugs.python.org (OBATA Akio)
Date: Wed, 22 Dec 2010 02:52:29 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1292986349.55.0.00536180284272.issue10475@psf.upfronthosting.co.za>


OBATA Akio <obata at lins.jp> added the comment:

CC and CXX will be set in configure script if not set.

----------
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10475>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:00:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 03:00:04 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1292986804.74.0.928254489643.issue2275@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No idea if this is even still valid (I skimmed the issue, I did not try to understand it in detail), but I agree that a change like this is more feature than bug fix, so I'm updating the issue settings accordingly.

----------
nosy: +r.david.murray
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:03:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 03:03:15 +0000
Subject: [issue4264] Patch: optimize code to use LIST_APPEND instead of
	calling list.append
In-Reply-To: <1225913493.68.0.578631463812.issue4264@psf.upfronthosting.co.za>
Message-ID: <1292986995.19.0.621181664099.issue4264@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4264>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:11:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 03:11:16 +0000
Subject: [issue2494] Can't round-trip datetimes<->timestamps prior to 1970 on
	Windows
In-Reply-To: <1206602826.96.0.687530064019.issue2494@psf.upfronthosting.co.za>
Message-ID: <1292987476.1.0.421116747908.issue2494@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Indeed, the time module is documented as not handling timestamps before the epoch.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2494>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:12:44 2010
From: report at bugs.python.org (Wang Yanjin)
Date: Wed, 22 Dec 2010 03:12:44 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292987564.82.0.159545033623.issue10754@psf.upfronthosting.co.za>


Wang Yanjin <wyj1046 at gmail.com> added the comment:

I encoutered this problem on Winxp sp3.

I have retested it on the win7, and it could return the correct value as it did on linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:16:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 03:16:06 +0000
Subject: [issue4322] function with modified __name__ uses original name when
	there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1292987766.98.0.137003325335.issue4322@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/issue4322>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:21:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 03:21:34 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292988094.1.0.25407008401.issue10754@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since the os functions tend to be small wrappers around system functions, this sounds like it is probably a platform issue and not a Python issue.  I'm adding our windows experts as nosy, they can reopen the issue if they disagree.

----------
nosy: +brian.curtin, tim.golden
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:32:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 03:32:05 +0000
Subject: [issue4369] Error building to a nonstandard prefix (with patch)
In-Reply-To: <1227203100.95.0.318644888004.issue4369@psf.upfronthosting.co.za>
Message-ID: <1292988725.63.0.806234984133.issue4369@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure what "compiling using a user prefix" means.  I've certainly specified a prefix containing my home directory and had things work just fine.

There isn't enough information here to know what is actually going wrong.  Since this issue is two years old I'm guessing the OP has moved on I am going to close it.  

If you are still interested and want to provide more info, Guiseppe, please reopen the issue and do so.

----------
nosy: +r.david.murray
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4369>
_______________________________________

From report at bugs.python.org  Wed Dec 22 04:48:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 22 Dec 2010 03:48:23 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292989703.88.0.694516597732.issue10754@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Just a random thought (no, I don't know anything about Windows): there are two "mu" characters: GREEK SMALL LETTER MU (?) and MICRO SIGN (?).  Normalization turns one into the other:

>>> from unicodedata import *
>>> name(normalize('NFKC', '\N{MICRO SIGN}'))
'GREEK SMALL LETTER MU'

it is possible that somehow the two characters get confused by OP system.

I could not reproduce the issue on OSX, so I won't reopen it.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 05:04:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 22 Dec 2010 04:04:09 +0000
Subject: [issue2275] urllib2 header capitalization
In-Reply-To: <1205270540.47.0.336665756101.issue2275@psf.upfronthosting.co.za>
Message-ID: <1292990649.31.0.5051738597.issue2275@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I think, we need to move forward with this. It is one of the earliest i worked on. I shall look at John's patch and look through it's inclusion in the code.

----------
assignee: facundobatista -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2275>
_______________________________________

From report at bugs.python.org  Wed Dec 22 05:29:40 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 04:29:40 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1292992180.78.0.40018712962.issue4761@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Ok, attached is a patch with the documentation updated as per recommendation.

----------
Added file: http://bugs.python.org/file20135/i4761_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Wed Dec 22 07:19:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 22 Dec 2010 06:19:03 +0000
Subject: [issue10754] os.path.isfile doesn't work with some greek characters
In-Reply-To: <1292982720.53.0.448142280407.issue10754@psf.upfronthosting.co.za>
Message-ID: <1292998743.49.0.429969251116.issue10754@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

On Windows, using the bytes APIs for filenames is unreliable and fails for characters that are not in the ANSI code page. So you should use

import os
for i in os.listdir(u'.'):
    print os.path.isfile(i), '\t', i

instead.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 08:26:16 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 07:26:16 +0000
Subject: [issue10755] Add posix.fdlistdir
In-Reply-To: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>
Message-ID: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

Along with #4761, the *at wrappers, it would be nice to have a patch adding the use of fdopendir.

This patch adds a function fdlistdir, a unittest and documentation.

----------
components: Extension Modules
files: i_fdlistdir.patch
keywords: patch
messages: 124489
nosy: Chris.Gerhard, anacrolix, benjamin.peterson, christian.heimes, durban, loewis, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Add posix.fdlistdir
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20136/i_fdlistdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10755>
_______________________________________

From report at bugs.python.org  Wed Dec 22 08:48:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 07:48:02 +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: <1293004082.1.0.485180953149.issue8732@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8732>
_______________________________________

From report at bugs.python.org  Wed Dec 22 08:58:36 2010
From: report at bugs.python.org (kai zhu)
Date: Wed, 22 Dec 2010 07:58:36 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

public at colinux 3 ~: python3.2
Python 3.2b2 (py3k, Dec 22 2010, 02:38:55) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import atexit; atexit.register(lambda:1/0)
<function <lambda> at 0xb7c7e12c>
>>> exit()
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found



might b related to Issue5089, so included those ppl to nosy.  this bug is subtle.  unit tests which explicitly 'raise' exceptions will not b caught, e.g. this will raise properly:

@exit.register
def foo(): raise ZeroDivisionError()

----------
components: Interpreter Core
messages: 124490
nosy: BreamoreBoy, kaizhu, mark.dickinson
priority: normal
severity: normal
status: open
title: Error in atexit._run_exitfuncs [...]  Exception expected for value, str found
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Wed Dec 22 09:13:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 08:13:08 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1293005588.52.0.126635621931.issue9017@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage: unit test needed -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Wed Dec 22 09:21:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 22 Dec 2010 08:21:55 +0000
Subject: [issue10755] Add posix.fdlistdir
In-Reply-To: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>
Message-ID: <1293006115.35.0.229963826608.issue10755@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the use case for this function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10755>
_______________________________________

From report at bugs.python.org  Wed Dec 22 09:24:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 08:24:04 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1293006244.49.0.899111985306.issue9085@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If there is no further discussion, I?d say the original bug is fixed anc this report should be closed.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Wed Dec 22 09:35:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 08:35:52 +0000
Subject: [issue8847] crash appending list and namedtuple
In-Reply-To: <1275087227.35.0.709211922869.issue8847@psf.upfronthosting.co.za>
Message-ID: <1293006952.61.0.664201446736.issue8847@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8847>
_______________________________________

From report at bugs.python.org  Wed Dec 22 09:43:48 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 08:43:48 +0000
Subject: [issue10755] Add posix.fdlistdir
In-Reply-To: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>
Message-ID: <1293007428.7.0.701514151311.issue10755@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

When maintaining an fd to implement a per thread current directory, you can use it to get a list of files in the directory.

For security reasons, instead of a named path, you can keep an fd to a directory so that if the path is changed externally while performing an operation, the open fd still points to the original directory. This function then allows you to list the contents of that fd. I think this is needed for #4489.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10755>
_______________________________________

From report at bugs.python.org  Wed Dec 22 09:54:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 08:54:56 +0000
Subject: [issue8885] markupbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1293008096.86.0.842688437762.issue8885@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
resolution: invalid -> 
stage:  -> needs patch
title: markerbase declaration errors aren't recoverable -> markupbase declaration errors aren't recoverable
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8885>
_______________________________________

From report at bugs.python.org  Wed Dec 22 10:02:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 09:02:23 +0000
Subject: [issue8964] platform._sys_version does not parse correctly IronPython
	2.x version
In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>
Message-ID: <1293008543.08.0.658594026983.issue8964@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to work on a patch?

----------
nosy: +eric.araujo
stage:  -> needs patch
title: Method _sys_version() module Lib\platform.py does not parse	correctly IronPython 2.x version -> platform._sys_version does not parse correctly IronPython 2.x version
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8964>
_______________________________________

From report at bugs.python.org  Wed Dec 22 10:05:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 09:05:01 +0000
Subject: [issue9074] subprocess closes standard file descriptors when it
	should not
In-Reply-To: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>
Message-ID: <1293008701.12.0.569962258302.issue9074@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
nosy: +astrand
stage:  -> patch review
title: [includes patch] subprocess module closes standard file descriptors when it should not -> subprocess closes standard file descriptors when it should not
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9074>
_______________________________________

From report at bugs.python.org  Wed Dec 22 10:21:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 09:21:02 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1293009662.84.0.560645252235.issue4489@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Wed Dec 22 10:47:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 09:47:24 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1293011244.68.0.928186189854.issue9399@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thinking again about that, what?s wrong with argparse replacing \n with spaces and doing its own line wrapping?

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9399>
_______________________________________

From report at bugs.python.org  Wed Dec 22 10:57:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Dec 2010 09:57:40 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1293011860.05.0.900937650941.issue8754@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I suppose it's not a good test, since your non-ascii name presumably was encoded in UTF-8, which is the encoding that PyUnicode_FromString uses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Wed Dec 22 11:10:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Dec 2010 10:10:33 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1293012633.05.0.0290802772015.issue4761@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reference counting is not always correct.  For example, in unlinkat

    if (res < 0)
        return posix_error();
    Py_DECREF(opath);
    (return None)

the DECREF should be before the error check.  (Note that you can use the Py_RETURN_NONE macro to save INCREF'ing Py_None explicitly.)

Sometimes you use posix_error, sometimes posix_error_with_allocated_filename; is that deliberate?

Also, the documentation for each function should get ".. versionadded:: 3.3" tags.

Otherwise, this looks good and ready for inclusion when py3k is open for new features again.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Wed Dec 22 12:53:43 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 11:53:43 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1293018823.7.0.0572288556918.issue4761@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

New patch *should* have fixed up reference counting and version tags.

I standardized all the error calls to posix_error.

----------
Added file: http://bugs.python.org/file20137/i4761_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Wed Dec 22 13:44:06 2010
From: report at bugs.python.org (=?utf-8?b?SmFjZWsgSmFixYJvxYRza2k=?=)
Date: Wed, 22 Dec 2010 12:44:06 +0000
Subject: [issue10757] zipfile.write, arcname should be bytestring
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>


New submission from Jacek Jab?o?ski <conexion2000 at gmail.com>:

file = 'somefile.dat'
filename = "?????????.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename)

above produces very nasty filename in zip archive.
*************************************************************
file = 'somefile.dat'
filename = "?????????.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename.encode('cp852'))

this produces TypeError: expected an object with the buffer interface

Documentation says that:
There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write().

I convert them to byte string but it ends with an error.
If it is documentation bug, what is the proper way to have filenames like "?????????" in zip archive?

----------
components: Library (Lib)
messages: 124499
nosy: connexion2000
priority: normal
severity: normal
status: open
title: zipfile.write, arcname should be bytestring
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Wed Dec 22 13:45:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Dec 2010 12:45:10 +0000
Subject: [issue10758] posix_access swallows all errors
In-Reply-To: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>
Message-ID: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

access(2) can return errnos that correspond to input errors or general system faults, such as EINVAL, EIO or ENOMEM.  In this case, an exception should be raised instead of returning False.

It is probably best to whitelist those errnos that indicate missing access -- it needs to be discussed whether that is just EACCES, or also e.g. ENOENT.

----------
components: Library (Lib)
messages: 124500
nosy: georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: posix_access swallows all errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10758>
_______________________________________

From report at bugs.python.org  Wed Dec 22 13:45:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Dec 2010 12:45:23 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1293021923.23.0.293500306158.issue4761@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the update! Three more comments:

* the new constants doc should also get a versionadded

* faccessat should check for EBADF, EINVAL and ENOTDIR and raise an error if they are returned, since these are input errors 

  Or, alternately, a range of errnos should be whitelisted for both access and faccessat.

  However, this problem should be handled in a separate issue, I've opened #10758 for that.

* The octal modes in docstrings and docs should be specified in Python 3 octal syntax, e.g. 0o777.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:04:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Dec 2010 13:04:31 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1293023071.64.0.573931807415.issue9990@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Antoine, a couple of questions:

(1) Is there documentation for the 'smalltable' field of the Py_buffer struct anywhere?  What are the requirements for the exporter here?  E.g., is it / should it be a requirement that shape, strides and suboffsets are all NULL whenever 'smalltable' is used?

(2) Same question for the 'obj' field:  what's the purpose of this field, from the POV of 3rd party buffer exporters?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:11:00 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 13:11:00 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1293023460.7.0.613145342478.issue4761@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This new patch has proper octal mode strings and another doc update.

I'll leave faccessat until #10758 has been resolved.

----------
Added file: http://bugs.python.org/file20138/i4761_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:11:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Dec 2010 13:11:54 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1293023071.64.0.573931807415.issue9990@psf.upfronthosting.co.za>
Message-ID: <1293023508.3680.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (1) Is there documentation for the 'smalltable' field of the Py_buffer
> struct anywhere?  What are the requirements for the exporter here?

No, and no particular requirements AFAIR. It is a piece of internal
storage aimed at avoiding the nagging allocation and ownership problem
(but only so when this storage is large enough, of course).

> E.g., is it / should it be a requirement that shape, strides and
> suboffsets are all NULL whenever 'smalltable' is used?

Not at all. On the contrary, smalltable can be used as a piece of
storage for some of these fields.

> (2) Same question for the 'obj' field:  what's the purpose of this
> field, from the POV of 3rd party buffer exporters?

None, it's used by the consumer side of the API, to know which object
exported the buffer and to keep a reference to it so that it doesn't get
deallocated early.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:23:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 13:23:39 +0000
Subject: [issue9085] Version number inconsistency in email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1293024219.07.0.884430908747.issue9085@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's too late to make any further changes in version numbers for 2.x.  Sorry this slipped by me.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9085>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:51:08 2010
From: report at bugs.python.org (Martin Potthast)
Date: Wed, 22 Dec 2010 13:51:08 +0000
Subject: [issue10759] HTMLParser.unescape() cannot handle HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>


New submission from Martin Potthast <martin.potthast at googlemail.com>:

The title says it all; try the minimal example.

----------
components: Library (Lib)
files: parser-fail.py
messages: 124506
nosy: Martin.Potthast
priority: normal
severity: normal
status: open
title: HTMLParser.unescape() cannot handle HTML entities with incorrect syntax (e.g. &#hearts;)
versions: Python 2.6
Added file: http://bugs.python.org/file20139/parser-fail.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:52:45 2010
From: report at bugs.python.org (Martin Potthast)
Date: Wed, 22 Dec 2010 13:52:45 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293025965.8.0.972784871662.issue10759@psf.upfronthosting.co.za>


Changes by Martin Potthast <martin.potthast at googlemail.com>:


----------
title: HTMLParser.unescape() cannot handle HTML entities with incorrect syntax (e.g. &#hearts;) -> HTMLParser.unescape() fails on HTML entities with incorrect syntax (e.g. &#hearts;)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:56:11 2010
From: report at bugs.python.org (Martin Potthast)
Date: Wed, 22 Dec 2010 13:56:11 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293026171.37.0.206609426832.issue10759@psf.upfronthosting.co.za>


Martin Potthast <martin.potthast at googlemail.com> added the comment:

I'd suggest to better verify the input and return such strings unchanged.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 14:56:19 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 22 Dec 2010 13:56:19 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1293026179.96.0.885099539157.issue10576@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Uh oh.  I forgot about this and there now we have passed beta 2.
Didn't anyone want to review the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Wed Dec 22 16:47:25 2010
From: report at bugs.python.org (Dennis Malcorps)
Date: Wed, 22 Dec 2010 15:47:25 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1293032845.15.0.083065188649.issue9399@psf.upfronthosting.co.za>


Dennis Malcorps <dennis.malcorps at googlemail.com> added the comment:

I totally forgot about this patch, sorry... Due to university and another python project I am working on I didn't find the time to look at the test suite. I would really appreciate it if someone else could do this ;-)

Anyway, I added the changes proposed by Steven Bethard and ?ric Araujo regarding the default argument values. (patch made against trunk)

@?ric:
Well, first there is currently only the 'version' action which does this and imho it just looks strange if you try to print something else than a version info with it.
Second, there are cases where you want whitespaces to be preserved, like printing out the license of your program (as I mentioned in my first post) Just look at this BSD license:

Copyright (c) 2010, Dennis Malcorps <dennis.malcorps at gmail.com> Redistribution
and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met: 1. Redistributions
of source code must retain the above copyright notice, this list of conditions                                                                       
and the following disclaimer. 2. Redistributions in binary form must reproduce                                                                       
the above copyright notice, this list of conditions and the following                                                                                
disclaimer in the documentation and/or other materials provided with the                                                                             
distribution. 3. The name of the author may not be used to endorse or promote                                                                        
products derived from this software without specific prior written permission.                                                                       
THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED                                                                           
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF                                                                                 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO                                                                           
EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.


This is just plain ugly.

----------
Added file: http://bugs.python.org/file20140/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9399>
_______________________________________

From report at bugs.python.org  Wed Dec 22 16:48:13 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 22 Dec 2010 15:48:13 +0000
Subject: [issue10758] posix_access swallows all errors
In-Reply-To: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>
Message-ID: <1293032893.48.0.160676425509.issue10758@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10758>
_______________________________________

From report at bugs.python.org  Wed Dec 22 16:48:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 15:48:58 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293032938.95.0.93900516359.issue10759@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Leaving the input unchanged does seem to be what browsers do.  (Issue 7626 has some info on browser behaviour with invalid entity refs.)

Rather than pre-validating the input, I think the exception can be caught and the putative entity returned unchanged, similar to how a keyerror is handled for a named entity.

Would you have any interest in proposing a patch and tests?

----------
nosy: +orsenthil, r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 17:28:26 2010
From: report at bugs.python.org (Frederic Torres)
Date: Wed, 22 Dec 2010 16:28:26 +0000
Subject: [issue8964] platform._sys_version does not parse correctly IronPython
	2.x version
In-Reply-To: <1293008543.08.0.658594026983.issue8964@psf.upfronthosting.co.za>
Message-ID: <AANLkTimP76GEXyKEQuG71kgY1RrYTEdfNu7V2Oi7=eU1@mail.gmail.com>


Frederic Torres <fredericaltorres at gmail.com> added the comment:

Eric,

Yes I like to.
But I am not familiar how to submit a patch.
The file that need to be patched is "C:\Program Files (x86)\IronPython
2.6\Lib\platform.py"  for IronPython 2.6.
I thought this file was maintained by Marc-Andre Lemburg
<mal at egenix.com based on the comment in the file platform.py.

It will affect IronPython 2.6 and  IronPython 2.6 For .Net 4.0 and
probably IronPython 2.7.

If you give me linsk to read about how to make a patch I would really
like to contribute to IronPython.

Thanks.
Fred.

On Wed, Dec 22, 2010 at 4:02 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Do you want to work on a patch?
>
> ----------
> nosy: +eric.araujo
> stage: ?-> needs patch
> title: Method _sys_version() module Lib\platform.py does not parse ? ? ?correctly IronPython 2.x version -> platform._sys_version does not parse correctly IronPython 2.x version
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8964>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8964>
_______________________________________

From report at bugs.python.org  Wed Dec 22 17:44:50 2010
From: report at bugs.python.org (Martin Potthast)
Date: Wed, 22 Dec 2010 16:44:50 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293036290.85.0.202001157464.issue10759@psf.upfronthosting.co.za>


Martin Potthast <martin.potthast at googlemail.com> added the comment:

Agreed. Here's a patch for HTMLParser. That was easy enough.

With regard to tests, there seems to be already one called test_malformatted_charref in test_htmlparser.py. However, the test tests the whole parser and not only HTMLParser.unescape().

At the same time, HTMLParser.unescape() has the following comment:
"# Internal -- helper to remove special character quoting"

It appears the syntax check is done in line 168 already, but since the unescape function is publicly visible, I'd say that it should be capable of handling all kinds of malformed input, despite that comment. Maybe this comment should be removed.

I'm not entirely sure how to write the test properly, since it doesn't fit into the framework provided by test_htmlparser.py; and unfortunately, my time is rather short at the moment.

----------
keywords: +patch
Added file: http://bugs.python.org/file20141/HTMLParser.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 17:52:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Dec 2010 16:52:46 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293036766.53.0.993085202289.issue10759@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, as an undocumented internal interface it may in fact not be appropriate to make this change.  Or it may be.  I'll have to look at the code in more detail to figure that out, or perhaps Senthil will.  (It may even be time to document the function, we'll see.)

Thanks for the patch.

----------
stage: needs patch -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 18:05:54 2010
From: report at bugs.python.org (Yoni Tsafir)
Date: Wed, 22 Dec 2010 17:05:54 +0000
Subject: [issue10760] tarfile doesn't handle sysfs well
In-Reply-To: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>
Message-ID: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>


New submission from Yoni Tsafir <yonix85+python at gmail.com>:

When I try to add a special file from sys, e.g.:
/sys/class/scsi_host/host0/cmd_per_lun (which is reported of size 4096 but actually reading it will return only several bytes of a result), I get the following exception:

Traceback (most recent call last):
  File "/opt/xpyv/lib/python26.zip/tarfile.py", line 1975, in add
    self.addfile(tarinfo, f)
  File "/opt/xpyv/lib/python26.zip/tarfile.py", line 2004, in addfile
    copyfileobj(fileobj, self.fileobj, tarinfo.size)
  File "/opt/xpyv/lib/python26.zip/tarfile.py", line 287, in copyfileobj
    raise IOError("end of file reached")
IOError: end of file reached

Notice what happens if I try to add the file with regular tar:
root at buzaglo # tar cvzf /tmp/blat.tgz /sys/class/scsi_host/host0/cmd_per_lun
tar: Removing leading `/' from member names
/sys/class/scsi_host/host0/cmd_per_lun
tar: /sys/class/scsi_host/host0/cmd_per_lun: File shrank by 4094 bytes; padding with zeros
tar: Error exit delayed from previous errors

So it handles the issue by padding the rest of the file size with zeros.

I think this should be the behavior as well, instead of throwing an IOError.

----------
components: None
messages: 124514
nosy: Yoni.Tsafir
priority: normal
severity: normal
status: open
title: tarfile doesn't handle sysfs well
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10760>
_______________________________________

From report at bugs.python.org  Wed Dec 22 19:12:57 2010
From: report at bugs.python.org (Eric Hohenstein)
Date: Wed, 22 Dec 2010 18:12:57 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1293041577.53.0.941486265639.issue9090@psf.upfronthosting.co.za>


Eric Hohenstein <ehohenstein at imvu.com> added the comment:

I have ported the changes related to this problem from the 3.2 branch to the 2.6 version of socketmodule.c. The changes are attached as a diff from Python 2.6.2. The changes apply to all platforms but I've only tested them on Windows.

The _PyTime_gettimeofday method is not available in 2.6 which is why the changes in 3.2 weren't originally back ported. I admit to adding a disgusting hack which was to copy some of the _PyTime_gettimeofday interface code from 3.2 to the socketmodule.c file and implement it using the time.time() method, falling back to the crt time() method. It's not as efficient as the implementation in 3.2 but I believe it should be equally correct.

The motivation for doing this was that I continued to see 10035 errors happening using Python 2.6 though in different code paths. Specifically, errors were being thrown when uploading a file using a PUT request using httplib which calls sendall(). It's noteworthy that analysing the changes made for this issue to Python 3.2 revealed that no change was made to the sendall() method. sendall() is actually problematic in that the timeout on the socket may actually be exceeded without error if any one call to select() doesn't exceed the socket's timeout but in aggregate the calls to select do wait longer than the timeout. The same generic solution that was applied to the other socket methods is not appropriate for sendall(). I elected to continue this behavior by just checking for EAGAIN and EWOULDBLOCK if the socket has a positive timeout value and the call to send failed and continuing the select/send loop in that case. As far as I can tell, sendall() will still fail with these recoverable errors in Python 3.2. I won't feel bad if this patch is rejected for 2.6 but the changes to sendall() should really be considered for the 3.2 branch.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 2.6 -Python 3.2
Added file: http://bugs.python.org/file20142/socket_10035.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Wed Dec 22 20:23:19 2010
From: report at bugs.python.org (Martin Potthast)
Date: Wed, 22 Dec 2010 19:23:19 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293045799.8.0.720226229295.issue10759@psf.upfronthosting.co.za>


Martin Potthast <martin.potthast at googlemail.com> added the comment:

Why not simply remove the additional check in line 168 and leave the responsibility to check the validity of its input to the unescape function (be it explicitly or, like now, lazily). That way, the code changes are minimal, the existing test covers the current issue, and the function gets more robust.

By the way, I came across this function via Stackoverflow:
http://stackoverflow.com/questions/2087370

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Wed Dec 22 20:57:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Dec 2010 19:57:38 +0000
Subject: [issue10758] posix_access swallows all errors
In-Reply-To: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>
Message-ID: <1293047858.95.0.102778312595.issue10758@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The list of errnos indicating missing access seems open-ended.
Things such as:

[ENAMETOOLONG]
    The length of a component of a pathname is longer than {NAME_MAX}.
[ENOENT]
    A component of path does not name an existing file or path is an empty string.
[ENOTDIR]
    A component of the path prefix is not a directory, or the path argument contains at least one non- <slash> character and ends with one or more trailing <slash> characters and the last pathname component names an existing file that is neither a directory nor a symbolic link to a directory.
[EROFS]
    Write access is requested for a file on a read-only file system.

... may be considered missing access.

----------
nosy: +pitrou
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10758>
_______________________________________

From report at bugs.python.org  Wed Dec 22 21:02:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Dec 2010 20:02:41 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1293048161.75.0.63804695139.issue10737@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10737>
_______________________________________

From report at bugs.python.org  Wed Dec 22 21:07:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 22 Dec 2010 20:07:50 +0000
Subject: [issue10757] zipfile.write, arcname should be bytestring
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293048470.22.0.0487104378431.issue10757@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug. Your code that produces "very nasty filename" is the right one - the file name is actually the one you asked for. The second code is also behaving correctly: filename already *is* a bytestring, calling .encode for it is meaningless.

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Wed Dec 22 21:12:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 22 Dec 2010 20:12:11 +0000
Subject: [issue10757] zipfile.write, arcname should be bytestring
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293048731.38.0.76723202165.issue10757@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Oops, I take this back - I didn't notice you were using Python 3.1.

In any case, your first code is correct. What you get is the best you can ask for.

That the second case fails is indeed a bug.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Wed Dec 22 21:16:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 22 Dec 2010 20:16:55 +0000
Subject: [issue10758] posix_access swallows all errors
In-Reply-To: <1293021910.31.0.818314214299.issue10758@psf.upfronthosting.co.za>
Message-ID: <1293049015.79.0.835484535656.issue10758@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think we can change this for the maintenance branches. The code behaves according to the documentation:

    access(path, mode) -> True if granted, False otherwise

"False otherwise" is really meant that way: otherwise. The specific condition is indeed not communicated. However, applications are entitled to not seeing exceptions come out of this function.

I would be in favor of changing this in the long term, but then raise exceptions in all cases. Alternatively, have it produce falsish values that encapsulate the error code.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10758>
_______________________________________

From report at bugs.python.org  Wed Dec 22 22:17:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 22 Dec 2010 21:17:44 +0000
Subject: [issue8964] platform._sys_version does not parse correctly IronPython
	2.x version
In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>
Message-ID: <1293052664.63.0.0640390553646.issue8964@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is the tracker for CPython, not IronPython, but I assume they synchronize their standard modules with ours, so I think this bug should be fixed here (not in 2.6 though, this old version only gets security fixes).

Guidelines for patches: http://www.python.org/dev/patches/

In short: check out the py3k branch, add a test that fails in Lib/test/test_platform.py (in the test_sys_version method), then patch the code to make the test pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8964>
_______________________________________

From report at bugs.python.org  Wed Dec 22 23:06:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Dec 2010 22:06:59 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1293055619.48.0.269150531776.issue10296@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10296>
_______________________________________

From orsenthil at gmail.com  Wed Dec 22 23:58:10 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 23 Dec 2010 06:58:10 +0800
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1292341337.1.0.503200318795.issue10587@psf.upfronthosting.co.za>
References: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
	<1292341337.1.0.503200318795.issue10587@psf.upfronthosting.co.za>
Message-ID: <20101222225810.GA1109@rubuntu>

On Tue, Dec 14, 2010 at 03:42:17PM +0000, Alexander Belopolsky wrote:
> I am attaching a patch that expands the documentation of isalnum,
> isalpha, isdecimal, isdigit, isnumeric, islower, isupper, and
> isspace.  I did not change isidentifier or isprintable because their
...
> redundant checks for isdecimal() and isdigit().  I think the
> documentation should reflect what the code does for an off-chance
> that someone would replace unicodedata with their own database with
> which these checks are not redundant.

+1 for making these changes. Helps clarify meaning of these methods with
respect to Unicode strings.


From report at bugs.python.org  Wed Dec 22 23:58:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 22 Dec 2010 22:58:24 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1292341337.1.0.503200318795.issue10587@psf.upfronthosting.co.za>
Message-ID: <20101222225810.GA1109@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

...
> redundant checks for isdecimal() and isdigit().  I think the
> documentation should reflect what the code does for an off-chance
> that someone would replace unicodedata with their own database with
> which these checks are not redundant.

+1 for making these changes. Helps clarify meaning of these methods with
respect to Unicode strings.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10587>
_______________________________________

From report at bugs.python.org  Thu Dec 23 01:17:16 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 23 Dec 2010 00:17:16 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

tarfile.extractall overwrites normal files and directories, yet it fails to overwrite symlinks:

  [..]
    tf.extractall()
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2167, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "/opt/ActivePython-2.7/lib/python2.7/tarfile.py", line 2243, in makelink
    os.symlink(tarinfo.linkname, targetpath)
OSError: [Errno 17] File exists

To reproduce, use a .tar.gz file containing relative (i.e., in the same directory) symlinks.

Perhaps it should delete `targetpath` before attempting to create a symlink.

----------
components: Library (Lib)
messages: 124523
nosy: srid
priority: normal
severity: normal
status: open
title: tarfile.extractall fails to overwrite symlinks
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Thu Dec 23 01:21:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Dec 2010 00:21:25 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293063685.52.0.7053974531.issue10730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Patch attached.

The instructions, after editing the url, are
    # Before adding new types, make sure they are either registered with IANA,
    # at http://www.iana.org/assignments/media-types
    # or extensions, i.e. using the x- prefix

Since there is no registration yet, I add the x- prefix. I presume that can be deleted without harm when it is registered. David, is that true?

Georg, is this OK for 3.2c1?
It can only break code depending on the entries not existing.

----------
assignee:  -> terry.reedy
keywords: +patch
Added file: http://bugs.python.org/file20143/mimetypes.svg.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 01:22:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Dec 2010 00:22:12 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293063732.01.0.645704666772.issue10730@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 01:59:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Dec 2010 00:59:31 +0000
Subject: [issue8885] markupbase declaration errors aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1293065971.03.0.363812728554.issue8885@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified the looping behavior of the testcase in both 2.7.1 and, with minor mods, 3.1.3 and 3.2b1, so this is a valid issue.

The HTMLParcer docs (2.7, 3.2) do not mention the .error method. The default is
    def error(self, message):
        raise HTMLParseError(message, self.getpos())

If this is *not* intended to be part of the api and over-ridden, the name should be changed to ._error and .error deprecated. If it is, it should be documented.

I think the self.error call should be followed either by j+=1 so parsing continues with the next char or by a raise statememt so it is definitely stopped.

----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8885>
_______________________________________

From report at bugs.python.org  Thu Dec 23 02:27:40 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Thu, 23 Dec 2010 01:27:40 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1293067660.01.0.812117607899.issue7511@psf.upfronthosting.co.za>


Thorsten Behrens <sbehrens at gmx.li> added the comment:

I can test this for 3.1, as all I have is the Express version of VC++. If you could point me towards a library that will work with 3.1 and has C components, that'll make the testing a lot easier. pycrypto and setuptools, the two libs mentioned in this issue, do not support Python 3.x.

----------
nosy: +sbehrens at gmx.li

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Dec 23 02:52:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 01:52:21 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293069141.78.0.0338938839056.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 11 of my patch:
 - Disable the fault handler (and displaying the backtrace on a fatal error) by default
 - The fault handle can be enabled by setting the PYTHONFAULTHANDLER environment variable or using "-X faulthandler" command line option (instead of being disabled by setting the PYTHONNOFAULTHANDLER env var)
 - Use PyGILState_GetThisThreadState() instead of _Py_atomic_load_relaxed(&_PyThreadState_Current) to get the state of the current thread, especially if the current thread doesn't hold the GIL
 - Add a protection against recursive calls to _Py_DisplayBacktrace() (a recursive call does nothing), even it is very unlikely
 - Don't repeat the exception message after the backtrace
 - Add a test on a segfault in a thread not holding the GIL

Disable the fault handler by default solves many issues reported on the python-dev mailing list:

 - Issues with embedded Python
 - Python 3.2 beta 2 is released
 - The fault handler supposes that the file descriptor 2 is the standard error output, but it may be a critical file or a network socket

Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough. The question is now how to enable the feature for a single run (reproduce a crash to try to get more information), not how to enable/disable it system-wide (because most developers agree that it should be disabled by default).

Should it be backported to Python 2.7 and 3.1?

----------
Added file: http://bugs.python.org/file20144/segfault_handler-11.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 02:52:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 01:52:38 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293069158.04.0.925424505931.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20102/segfault_handler-9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 02:52:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 01:52:40 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293069160.72.0.157163096387.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20113/segfault_handler-10.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 02:52:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 01:52:53 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293069173.46.0.898743502378.issue8863@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/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 03:04:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Dec 2010 02:04:05 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293069845.51.0.209797848622.issue8863@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Stephen,

I wonder if you would have comments on this.  As far as I know emacs installs SEGV handlers similar to the ones proposed here.  How well do they work?  Does it really help users to produce meaningful bug reports?

----------
nosy: +belopolsky, sjt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 03:27:03 2010
From: report at bugs.python.org (Scott Dial)
Date: Thu, 23 Dec 2010 02:27:03 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1293069141.78.0.0338938839056.issue8863@psf.upfronthosting.co.za>
Message-ID: <4D12B36E.6000309@scottdial.com>


Scott Dial <scott at scottdial.com> added the comment:

On 12/22/2010 8:52 PM, STINNER Victor wrote:
> Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough.

I really think you should think of it as a choice the developer of an
application makes instead of a choice an application user makes. A
setsegfaultenabled() could just be another step of initializing the
application akin to setting up the logging module, for instance. In that
situation, a function call has a much lower barrier for use than a CLI
option or environment variable where you'd have to create a wrapper script.

----------
title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV,	SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 03:32:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Dec 2010 02:32:01 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1293071521.1.0.171026559497.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed to py3k in revision 87442.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Thu Dec 23 03:45:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Dec 2010 02:45:48 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <4D12B36E.6000309@scottdial.com>
Message-ID: <AANLkTikRtTK-kNHOGWrXhfQYCsHGztmwc8mteOWbjSnX@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 22, 2010 at 9:27 PM, Scott Dial <report at bugs.python.org> wrote:
>
> Scott Dial <scott at scottdial.com> added the comment:
>
> On 12/22/2010 8:52 PM, STINNER Victor wrote:
> > Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough.
>
> I really think you should think of it as a choice the developer of an
> application makes instead of a choice an application user makes. A
> setsegfaultenabled() could just be another step of initializing the
> application akin to setting up the logging module, for instance. In that
> situation, a function call has a much lower barrier for use than a CLI
> option or environment variable where you'd have to create a wrapper script.

+1

I would actually prefer just sys.setsegfaultenabled() without a
controlling environment variable.  If necessary, the environment
variable can be checked in site.py and sys.setsegfaultenabled()
called.

As I suggested on python-dev, I also think this belongs to a separate
module rather than core or sys.  The relevant code is already
segregated in a file, so turning it into a module should not be
difficult.  The only function that probably must stay in core is
_Py_DumpBacktrace().  With say "segvhandler" module, site.py can
include something like this:

if sys.getenv('PYTHONSEGVHANDLER'):
     import segvhandler
     segvhandler.enable()

Does the latest patch address the GIL/multithreading issues?

----------
title: Display Python backtrace on SIGSEGV,	SIGFPE and fatal error -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 04:02:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Dec 2010 03:02:13 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1293073333.48.0.375848193468.issue10587@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed r87443 (3.2) and r87444 (3.1).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10587>
_______________________________________

From report at bugs.python.org  Thu Dec 23 04:30:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 03:30:39 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293075039.71.0.696319915964.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Does the latest patch address the GIL/multithreading issues?

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 04:32:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 03:32:47 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <4D12B36E.6000309@scottdial.com>
Message-ID: <1293075182.12866.34.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 23 d?cembre 2010 ? 02:27 +0000, Scott Dial a ?crit :
> Scott Dial <scott at scottdial.com> added the comment:
> 
> On 12/22/2010 8:52 PM, STINNER Victor wrote:
> > Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough.
> 
> I really think you should think of it as a choice the developer of an
> application makes instead of a choice an application user makes.

Why do you think so? Can you give me an use case of
sys.setsegfaultenabled()?

Extract of my email on python-dev:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 04:35:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 03:35:58 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <4D12B36E.6000309@scottdial.com>
Message-ID: <1293075373.12866.37.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 23 d?cembre 2010 ? 02:27 +0000, Scott Dial a ?crit :
> Scott Dial <scott at scottdial.com> added the comment:
> 
> On 12/22/2010 8:52 PM, STINNER Victor wrote:
> > Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough.
> 
> I really think you should think of it as a choice the developer of an
> application makes instead of a choice an application user makes.

Why do you think so? Can you give me an use case of
sys.setsegfaultenabled()?

Extract of my email on python-dev:

  Use case: when a program crashs, the user reruns its application 
  with the fault handler enabled and tries to reproduce the crash.
  He/She can send the Python backtrace to the developer, or use
  it directly (if he/she understands it).

After the discussion on python-dev, I don't think that the fault handler
should be enabled by default, but only for a single run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 04:38:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 03:38:16 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <AANLkTikRtTK-kNHOGWrXhfQYCsHGztmwc8mteOWbjSnX@mail.gmail.com>
Message-ID: <1293075511.12866.39.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 23 d?cembre 2010 ? 02:45 +0000, Alexander Belopolsky a ?crit :
> As I suggested on python-dev, I also think this belongs to a separate
> module rather than core or sys.

Why do you want to move it outside Python core? It is very dependent of
Python internals (GIL/threads, frames, etc.) and so I think that it's
better to keep it in the Python core.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 04:45:30 2010
From: report at bugs.python.org (Scott Dial)
Date: Thu, 23 Dec 2010 03:45:30 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1293075373.12866.37.camel@marge>
Message-ID: <4D12C5D2.2030309@scottdial.com>


Scott Dial <scott at scottdial.com> added the comment:

On 12/22/2010 10:35 PM, STINNER Victor wrote:
> Why do you think so? Can you give me an use case of
> sys.setsegfaultenabled()?

To feed back your own argument on python-dev:

> How do you know that you application will crash? The idea is to give
> informations to the user when an application crashs: the user can use
> the backtrace or send it to the developer. Segmentation faults are
> usually not (easilly) reproductible :-( So even if you enable the
> fault handler, you may not be able to replay the crash. Or even
> worse, the fault may not occurs at all when you enable the fault
> handler... (Heisenbugs!)

> After the discussion on python-dev, I don't think that the fault handler
> should be enabled by default, but only for a single run.

I agree that it should be disabled by default because of the potential
do bad things if the application was not wrote with it in mind. But an
application developer would be in a much better position to decide what
the default should be for their application if they believe they will be
able to get more useful bug reports from their users by enabling it.

I thought that was your position, but if you no longer believe that,
then I will not push for it.

----------
title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display Python backtrace on SIGSEGV,	SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 05:52:49 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 23 Dec 2010 04:52:49 +0000
Subject: [issue10755] Add posix.fdlistdir
In-Reply-To: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>
Message-ID: <1293079969.6.0.467616572257.issue10755@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Hi,

Attached is a slightly updated patch that improves doc and changes fdlistdir to always return strings, not bytes.

----------
Added file: http://bugs.python.org/file20145/i10755.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10755>
_______________________________________

From report at bugs.python.org  Thu Dec 23 09:46:14 2010
From: report at bugs.python.org (Grygoriy Fuchedzhy)
Date: Thu, 23 Dec 2010 08:46:14 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293093974.21.0.921540748465.issue10730@psf.upfronthosting.co.za>


Grygoriy Fuchedzhy <grygoriy.fuchedzhy at gmail.com> added the comment:

Shouldn't .svgz be also added as 'image/x-svg+xml'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 10:13:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Dec 2010 09:13:59 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293095639.58.0.357652398022.issue10730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

No, the other combined suffixes are not either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 10:42:42 2010
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Thu, 23 Dec 2010 09:42:42 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293097362.13.0.273694363871.issue8863@psf.upfronthosting.co.za>


Stephen J. Turnbull <stephen at xemacs.org> added the comment:

Re: msg124528

Yes, XEmacs installs a signal handler on what are normally fatal errors.  (I don't know about GNU Emacs but they probably do too.)

The handler has two functions: to display a Lisp backtrace and to output a message explaining how to report bugs (even including a brief introduction to the "bt" command in gdb. ;-)

I personally have never found the Lisp backtrace useful, except that it can be used as a bug signature of sorts ("oh, I think I've seen this one before...").  However, I suspect this is mostly because in Emacs Lisp very often you don't have the name of the function in the backtrace, only a compiled code object.  So in many cases it's almost no help in localizing the fault.  Victor's patch does a lot better on this than XEmacs can, I suspect.

The bug reporting message, OTOH, has been useful to us for the reasons people give for wanting the handler installed by default.  We get more and better bug reports, often including C backtraces, from people who have never participated directly in XEmacs development before.  (It also once served the function of inhibiting people from sending us core files. Fortunately, I don't think that happens much any more. :-)  Occasionally a user will be all proud of themselves because "I never used gdb before," so I'm pretty sure that message is effective.

Quite frequently we see the handler itself crash if there was memory corruption, but certainly it gives useful output well over half the time.  So I want to back up Victor on those aspects.

Finally, although our experience has be very positive, qnote that XEmacs is not an embeddable library, nor is there provision in the mainline versions for embedding other interpreters in XEmacs.  So we've never had to worry about the issues that come with that.

For more technical details, you could ask Ben Wing <ben at xemacs.org> who put a lot of effort into the signal handling implementation, or Hrvoje Niksic (sorry, no address offhand) who posts on python-dev occasionally.  (I don't know if Hrvoje ever worked on the signal handlers, and he hasn't worked on XEmacs for years, but he was more familiar with internals than me then, and might very well still remember more than I ever knew. :-)  I don't think either will disagree with my general statements above, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 10:57:42 2010
From: report at bugs.python.org (David Leonard)
Date: Thu, 23 Dec 2010 09:57:42 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>


New submission from David Leonard <d+python at adaptive-enterprises.com>:

Installed http://www.python.org/ftp/python/2.7.1/python-2.7.1.amd64.msi
on Windows 7, x64 into C:\Python27

C:\>\Python27\python.exe
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime('%f')

Dialog raises: "Python.exe has stopped working"

----------
components: Library (Lib)
messages: 124542
nosy: dleonard0
priority: normal
severity: normal
status: open
title: strftime('%f') segfault
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10762>
_______________________________________

From report at bugs.python.org  Thu Dec 23 11:45:05 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Dec 2010 10:45:05 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1293101105.37.0.827588573624.issue7511@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Before anyone does any further testing:

Tarek, can this go into distutils 2.7/3.2 (after 3.2 has been released)?
Due to the popularity of this issue I think it might be worthwhile to
make an exception and ignore the distutils freeze.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From theller at ctypes.org  Thu Dec 23 11:11:18 2010
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 23 Dec 2010 11:11:18 +0100
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1293055619.48.0.269150531776.issue10296@psf.upfronthosting.co.za>
References: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
	<1293055619.48.0.269150531776.issue10296@psf.upfronthosting.co.za>
Message-ID: <iev786$lud$1@dough.gmane.org>

ctypes has _always_ catched exceptions raised in function calls.
On Windows ;-).


From report at bugs.python.org  Thu Dec 23 12:10:32 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Dec 2010 11:10:32 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293102632.98.0.0863779106238.issue8863@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[Alexander]

if sys.getenv('PYTHONSEGVHANDLER'):
     import segvhandler
     segvhandler.enable()

+1

If this doesn't find support, I'd name sys.setsegfaultenabled()
sys.setsegvhandlerenabled() or sys.enable_segvhandler().

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 12:29:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 11:29:21 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293103761.95.0.79320822784.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: To avoid the signal-safe requirement, another solution is to use sigsetjmp()+siglongjmp().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 12:58:23 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 23 Dec 2010 11:58:23 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1293105503.01.0.721102449453.issue10743@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have investigated the problem and it turns out virtualenv patches distutils.sysconfig behavior by adding to the sys module a "real_prefix" attribute that points to the global Python install and is used instead of sys.prefix that points to the virtualenv local install, when some distutils.sysconfig APIs are used.

The fix is to change virtualenv so it patches sysconfig the same way it does for distutils.sysconfig.

To simulate this patch, just change how _EXEC_PREFIX and _PREFIX are set in sysconfig, by setting them to sys.real_prefix instead of sys.prefix/sys.exec_prefix when using virtualenv. 

I suggest to Georg that this bug gets resolved to "invalid" and that we move it to the virtualenv bitbucket tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Thu Dec 23 12:59:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 11:59:28 +0000
Subject: [issue10763] subprocess.communicate() doesn't close pipes on Windows
In-Reply-To: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>
Message-ID: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If more than one file (stdin, stdout and stderr) are pipes, Popen.communicate() uses threads calling _readerthread() on each pipe. But this method doesn't close the pipes, whereas all other communicate implementations (select, poll and the optimization if there is only one pipe) do close all pipes.

Attached patch fixes this issue.

Thanks Antoine for your nice ResourceWarning patch!

----------
components: Library (Lib), Windows
files: subprocess_close_pipes.patch
keywords: patch
messages: 124547
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess.communicate() doesn't close pipes on Windows
versions: Python 3.2
Added file: http://bugs.python.org/file20146/subprocess_close_pipes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10763>
_______________________________________

From report at bugs.python.org  Thu Dec 23 12:59:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 11:59:52 +0000
Subject: [issue10763] subprocess.communicate() doesn't close pipes on Windows
In-Reply-To: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>
Message-ID: <1293105592.51.0.217464070025.issue10763@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +amaury.forgeotdarc, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10763>
_______________________________________

From report at bugs.python.org  Thu Dec 23 13:02:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 12:02:54 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293105774.37.0.32094770851.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested the patch version 11 on Windows: all tests pass. But #include <unistd.h> should be skipped on Windows (Python/fault.c): I will add #ifdef MS_WINDOWS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 13:11:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 12:11:05 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293106265.82.0.0583088335525.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I tested the patch version 11 on Windows: all tests pass.

Oh, and I forgot to say that the Windows fault handler does catch the fault too (Windows opens a popup with a question like "Should the error be reported to Microsoft?").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 13:12:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 12:12:35 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293106355.41.0.615938546881.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Tested on FreeBSD 8: all tests pass (all of the 4 signals are supported) and FreeBSD dumps a core file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 13:31:09 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Dec 2010 12:31:09 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1293103761.95.0.79320822784.issue8863@psf.upfronthosting.co.za>
Message-ID: <20101223123059.GA32281@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> Note: To avoid the signal-safe requirement, another solution is to use sigsetjmp()+siglongjmp().

FWIW, there is a caveat in the OpenBSD man page concerning the use of
siglongjmp():

http://www.openbsd.org/cgi-bin/man.cgi?query=sigsetjmp&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=htm

"Use of longjmp() or siglongjmp() from inside a signal handler is not as
 easy as it might seem.  Generally speaking, all possible code paths
 between the setjmp() and longjmp() must be signal race safe, as discussed
 in signal(3).  Furthermore, the code paths must not do resource
 management (such as open(2) or close(2)) without blocking the signal in
 question, or resources might be mismanaged.  Obviously this makes
 longjmp() much less useful than previously thought."

----------
title: Display Python backtrace on SIGSEGV,	SIGFPE and fatal error -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 13:33:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 12:33:37 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293107617.32.0.306683317992.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Tested on Ubuntu 10.04: all tests pass and apport intercepts the fault. Apport ignores the faults because I am testing a Python executable compiled from SVN (py3k). Apport logs (/var/log/apport.log):
---
apport (pid 18148) Thu Dec 23 13:29:25 2010: called for pid 18147, signal 8
apport (pid 18148) Thu Dec 23 13:29:25 2010: executable: /home/haypo/prog/SVN/py3k/python (command line "./python -c import\ _testcapi;\ _testcapi.sigfpe()")
apport (pid 18148) Thu Dec 23 13:29:25 2010: executable does not belong to a package, ignoring
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Dec 23 14:43:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Dec 2010 13:43:31 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1293111811.96.0.301395902841.issue7511@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IIUC, the issue is that people installing a 64-bit Python, and VS Express, and then wonder why they can't build extension modules. I'm not so sure that there is a bug in Python here - this setup is not supported (and that's really Microsoft's fault). Now, automatically finding the SDK would be a new feature, IMO: if you want to use SDK tools, you are supposed to set DISTUTILS_USE_SDK, after opening the respective build environment. IIUC, installing VS express would not have been necessary in this setup at all - just install the SDK.

Alternatively, people can install Visual Studio proper, or use a 32-bit Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Dec 23 15:58:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 14:58:27 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1293116307.08.0.772866449352.issue10762@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that this is a regression relative to 2.6, where the same call returns '' (which is different from what it returns on linux, where the result would be '%f', or OSX, where the result would be 'f').  (Tests done on windows XP using pythons installed from the python.org installers.)

My guess is that the difference between python 2.6 and python 2.7+ is issue 4804.  I'm therefore adding the nosy list from that issue to this one.

For the OP's benefit: my guess is that this is a bug in the Microsoft C runtime, but we probably need to provide a workaround for it in Python.

----------
nosy: +amaury.forgeotdarc, krisvale, loewis, mhammond, ocean-city, r.david.murray
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10762>
_______________________________________

From report at bugs.python.org  Thu Dec 23 15:58:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 23 Dec 2010 14:58:50 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293116330.49.0.334906315275.issue10759@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, I too agree that HTMLParser.unescape() should split-out malformed char-ref just as other browsers do.

But, as unescape function has undocumented/unexposed for releases, I am not sure making it exposed is a good idea. HTMLParser is more for event based parsing of tags, and unescape is a just a helper function in that context.

Given that reasoning if you see the malformatted test, you see that event based parsing does return the malformatted data properly For e.g -  ("data", "&#bad;").

Only calling unescape explicitly does not exhibit this behavior.

Martin: I am not sure if changing something in line 168 would solve the issue. In that particular block of code, the else condition is responsible for throwing the malformed charref on an event. If would like to elaborate a bit more on your suggestion, it would be helpful.

However, I do agree that unescape can be changed as per your patch and I have added a simple test to exercise that change. I think, this can go in.

----------
assignee:  -> orsenthil
stage: unit test needed -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file20147/Issue10759.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Thu Dec 23 16:33:24 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Thu, 23 Dec 2010 15:33:24 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1293118404.02.0.794525549921.issue7511@psf.upfronthosting.co.za>


Thorsten Behrens <sbehrens at gmx.li> added the comment:

You are right, this is not a bug in Python. The diff provides a workaround for a limitation in VC++ 2008 Express. This diff is a piece of user service.

An equally as workable workaround is for the user to copy VC\bin\vcvars64.bat into VC\bin\amd64\vcvarsamd64.bat. Once that is done, distutils works without the workaround provided in this diff.

Whether to provide a workaround within Python for an issue in VC++ 2008 Express can certainly be debated. I for one suggest to err on the side of being friendly, rather than insisting on purity.

Consider that users of Python do include hobbyists and students. For them, VC++ Pro may be out of reach. And there are plenty of reasons for building 64-bit binaries, among them learning exercises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Dec 23 17:12:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 16:12:43 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293120763.6.0.855879997964.issue10730@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I believe the patch should add the used but non-standard image/svg+xml type to the common_type dictionary, not invent a new x- type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 18:26:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 17:26:45 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1293125205.71.0.782264589112.issue9319@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

p3k_i9313.diff is just a workaround, not the correct fix. The problem is that PyTokenizer_FindEncoding() doesn't get the filename.

I wrote tokenizer_encoding_filename.patch which add PyTokenizer_FindEncodingFilename() and patch import.c and traceback.c to pass the filename.

Hum, I'm not sure that my patch works if the locale encoding is not UTF-8: import.c manipulates path in the filesystem encoding, whereas PyTokenizer_FindEncodingFilename() expects UTF-8 filename.

See this patch as a draft, I will try to fix the encoding issue.

----------
Added file: http://bugs.python.org/file20148/tokenizer_encoding_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Thu Dec 23 18:28:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Dec 2010 17:28:14 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1293125294.65.0.488615820209.issue9319@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #9738 (Document the encoding of functions bytes arguments of the C API) to check which encoding is expected :-p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Thu Dec 23 18:56:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Dec 2010 17:56:24 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

sysconfig assumes there will be a makefile if the platform is posix, which isn't always true. For example IronPython on Mac OS X with mono.

This leads to a traceback on startup with IronPython 2.7:

$ ipy27
Traceback (most recent call last):
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 548, in <module>
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 530, in main
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 264, in addusersitepackages
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 239, in getusersitepackages
  File "/Second/michael/Downloads/IronPython-2.7/Lib/site.py", line 229, in getuserbase
  File "/Second/michael/Downloads/IronPython-2.7/Lib/sysconfig.py", line 518, in get_config_var
  File "/Second/michael/Downloads/IronPython-2.7/Lib/sysconfig.py", line 421, in get_config_vars
  File "/Second/michael/Downloads/IronPython-2.7/Lib/sysconfig.py", line 275, in _init_posix
IOError: invalid Python installation: unable to open /Volumes/Second Drive/michael/Downloads/IronPython-2.7/lib/python2.7/config/Makefile (Could not find a part of the path "/Volumes/Second Drive/michael/Downloads/IronPython-2.7/lib/python2.7/config/Makefile".)IronPython 2.7 Beta 1 (2.7.0.10) on .NET 4.0.30319.1
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
messages: 124560
nosy: eric.araujo, michael.foord, tarek
priority: normal
severity: normal
status: open
title: sysconfig and alternative implementations
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Thu Dec 23 19:21:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 18:21:21 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293128481.61.0.363216703343.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, adding the x- version would probably be pointless as most likely nobody uses it.

Has anyone found any definitive info on where exactly in the approval process image/svg+xml is?

I think we should probably just go ahead and put it in, but it would be nice to link to some mailing list discussion somewhere that indicates that it is solidly standards track.

I found a mailing list posting from 2000 about browser support.

I found this: http://www.w3.org/TR/SVG/intro.html from June 2010 saying the registration was in progress at the w3c.  How w3c registration relates to IANA registration is not entirely clear, but most likely IANA wouldn't register it without w3c approving it first.

RFC 3023 mentions it and says it hasn't been approved yet so it shouldn't be used.  That was in 2001.

Why the incredibly long delay?

As best as I can guess, the mime-type registration is conditioned on the acceptance of the underlying SVG standard it references, and that standard (SVG 1.1) has not yet been ratified by the W3C, which is, if I'm underanding the RFCs correctly, required for IANA approval of the media type request.  SVG 1.1 has, according to wikipedia, been put out for Last Call.

All of which seems pretty irrelevant to the value and likely stability of the image/svg+xml name itself.  Since all the major browsers are supporting it, as far as I can tell, I think Python should too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 19:27:10 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 23 Dec 2010 18:27:10 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1293128830.67.0.273784461911.issue10743@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Sounds good, but this doesn't belong to the virtualenv bug tracker (virtualenv does even support Python 3). Instead, it belongs to the virtualenv5 tracker: http://code.google.com/p/virtualenv5/issues/detail?id=6

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Thu Dec 23 19:37:03 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 23 Dec 2010 18:37:03 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1293129423.02.0.210641666164.issue7511@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Purity shmurity. The point of distutils is largely to present a unified and simple interface. 'python setup.py install' should be all a user has to do on any platform. Unless you can come up with a better idea, MSVC is really the only big compiler on Windows.

----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Thu Dec 23 19:56:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Dec 2010 18:56:37 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293130597.91.0.893616116869.issue10730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I obviously misunderstood the instruction about 'x-' and will remove that. Should I leave the entry where it is or move as ?ric suggested?

----------
Added file: http://bugs.python.org/file20149/mimetypes.svg2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 20:00:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 19:00:23 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293130823.7.0.637889242594.issue10730@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure; the common_types is actually for invalid but used types, like image/jpg (the correct one is image/jpeg and is listed in types_map).  The status of IANA registration is unclear (thanks David for looking at that); since common tools understand that media type, let?s pretend it?s registered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 20:00:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 19:00:32 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293130832.71.0.312573797886.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, I don't think it qualifies as a common_type.

But since this is technically a feature request we need Georg's approval for the commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 20:53:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 19:53:01 +0000
Subject: [issue4496] misleading comment in urllib2
In-Reply-To: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za>
Message-ID: <1293133981.83.0.385730959337.issue4496@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is used in the tests, but I agree that it doesn't appear to be used in the code.  I've removed the misleading comment and marked the self.handlers attribute as backward-compat-only in r87448, r87449, and r87450.

The sorting is based on a 'handler_order' attribute, by the way, and presumably does control the order in which they are applied.

----------
nosy: +jhylton, r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4496>
_______________________________________

From report at bugs.python.org  Thu Dec 23 21:41:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 20:41:20 +0000
Subject: [issue1155362] Bugs in parsedate_tz
Message-ID: <1293136880.7.0.335447618472.issue1155362@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed a slightly different patch in r87451, with tests.  Although I do consider this a bug fix, it hasn't apparently caused any problems in real life and does represent a slight behavior change, so I'm not backporting it.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1155362>
_______________________________________

From report at bugs.python.org  Thu Dec 23 22:14:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 21:14:16 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293138856.69.0.0745675901377.issue10730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Got approval from Georg on IRC, so go ahead and commit it, Terry.  Or assign it to me if you'd rather I do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Thu Dec 23 22:26:23 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Thu, 23 Dec 2010 21:26:23 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1293139583.52.0.187104115265.issue10576@psf.upfronthosting.co.za>


Lukas Lueg <lukas.lueg at gmail.com> added the comment:

Why not make the start-callback be able to return a boolean value to the gcmodule that indicates if garbage collection should take place or not.

For example, any value returned from the callback that evaluates to False (like null) will cause the module to evaluate any other callback and possibly collect garbage objects. Any value that evaluates to True (like True) returned from any callback causes all further callbacks to not be called and garbage collection not to take place now.

----------
nosy: +ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Thu Dec 23 22:55:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 21:55:15 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1293141315.66.0.109588617208.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can?t reproduce the crash when building in the source dir (and tests pass except for ctypes because its configure script refuses my directory path), and I can?t build in a subdir*, so this bug looks fixed.

* Error messages:
gcc: Parser/tokenizer_pgen.o: No such file or directory
gcc: Parser/printgrammar.o: No such file or directory
gcc: Parser/pgenmain.o: No such file or directory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:07:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 23:07:42 +0000
Subject: [issue1693546] email.Message set_param rfc2231 encoding incorrect
Message-ID: <1293145662.07.0.442878689881.issue1693546@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Reading the RFC again, I think you are right.  The quoted vs unquoted sounds like it refers to the *n vs the [*n]* forms, and the latter doesn't use quoted strings but % encoding.

I'm attaching a patch that adds some tests and fixes this.  It's a visible behavior change so it won't be backported.  Clearly mailers accept the quoted form, but we prefer to be strictly RFC compliant on output.  The behavior change is that whereas previously unquoted values on parse got quotes added on serialization, now quoted values on parse will lose their quotes on serialization.

----------
keywords: +patch
stage: unit test needed -> patch review
versions:  -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20150/rfc2231_quoting.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693546>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:13:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Dec 2010 23:13:44 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1293146024.61.0.48012933261.issue10730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

r87460

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:16:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Dec 2010 23:16:54 +0000
Subject: [issue1693546] email.Message set_param rfc2231 encoding incorrect
Message-ID: <1293146214.54.0.984364204875.issue1693546@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I take it back.  Previously quotes didn't get added if they weren't already there.  So my simpleminded fix may not be the best choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693546>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:19:07 2010
From: report at bugs.python.org (Martin)
Date: Thu, 23 Dec 2010 23:19:07 +0000
Subject: [issue10765] Build regression from automation changes on windows
In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za>
Message-ID: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

The build changes in r87093 broke me, as my py3k branch is under a dir with a space in the name, and the OutDir path needs escaping in the makefiles. Various extra quoting seems to be sufficient, though inelegant.

----------
components: Build, Windows
files: py3k_build.patch
keywords: patch
messages: 124575
nosy: gz, loewis
priority: normal
severity: normal
status: open
title: Build regression from automation changes on windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20151/py3k_build.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10765>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:29:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 23:29:49 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1293146989.66.0.223680657831.issue4391@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Updated patch for optparse.  Georg: Is this okay for 3.2?

Based on Steven?s decision for another patch that changed strings, these fixes won?t be backported.

----------
versions:  -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20152/fix-optparse-ngettext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:38:55 2010
From: report at bugs.python.org (Martin)
Date: Thu, 23 Dec 2010 23:38:55 +0000
Subject: [issue10765] Build regression from automation changes on windows
In-Reply-To: <1293146347.8.0.828425848028.issue10765@psf.upfronthosting.co.za>
Message-ID: <1293147535.51.0.730576934523.issue10765@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

Oh, and after building with this, I get:

$ svn st
?       PC/python3dll.obj

So either that wants moving or svn:ignore needs updating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10765>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:59:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 23:59:13 +0000
Subject: [issue10766] optparse uses %s in gettext calls
In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>
Message-ID: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When you run xgettext other optparse.py, you get this warning:
?'msgid' format string with unnamed arguments cannot be properly localized: The translator cannot reorder the arguments.  Please consider using a format string with named arguments, and a mapping instead of a tuple for the arguments.?

Attached patch fixes the incorrect calls (my patch for #4391 already fixes two of them).

See similar bug and fix for argparse in #10528.  Georg, please tell if this can go into 3.2.

----------
assignee: eric.araujo
components: Library (Lib)
files: fix-gettext-positionals.diff
keywords: patch
messages: 124578
nosy: eric.araujo, georg.brandl, gward
priority: normal
severity: normal
stage: commit review
status: open
title: optparse uses %s in gettext calls
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20153/fix-gettext-positionals.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10766>
_______________________________________

From report at bugs.python.org  Fri Dec 24 00:59:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 23 Dec 2010 23:59:22 +0000
Subject: [issue10766] optparse uses %s in gettext calls
In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>
Message-ID: <1293148762.48.0.110089779761.issue10766@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +use proper gettext plurals forms in argparse and optparse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10766>
_______________________________________

From report at bugs.python.org  Fri Dec 24 01:10:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 00:10:12 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1293149412.9.0.247430501849.issue6280@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Fri Dec 24 01:29:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 00:29:40 +0000
Subject: [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1293150580.78.0.605044579404.issue9063@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r87463 (3.2), r87464 (2.7) and r87465 (3.1).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9063>
_______________________________________

From report at bugs.python.org  Fri Dec 24 01:52:42 2010
From: report at bugs.python.org (John Machin)
Date: Fri, 24 Dec 2010 00:52:42 +0000
Subject: [issue7198] Extraneous newlines with csv.writer on Windows
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1293151962.88.0.236494852663.issue7198@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Please re-open this. The binary/text mode problem still exists with Python 3.X on Windows. Quite simply, there is no option available to the caller to open the output file in binary mode, because the module is throwing str objects at the file. The module's idea of "taking control" in the default case appears to be to write \r\n which is then processed by the Windows runtime and becomes \r\r\n.

Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> f = open('terminator31.csv', 'w')
>>> row = ['foo', None, 3.14159]
>>> writer = csv.writer(f)
>>> writer.writerow(row)
14
>>> writer.writerow(row)
14
>>> f.close()
>>> open('terminator31.csv', 'rb').read()
b'foo,,3.14159\r\r\nfoo,,3.14159\r\r\n'
>>>

And it's not just a row terminator problem; newlines embedded in fields are likewise expanded to \r\n by the Windows runtime.

----------
nosy: +sjmachin
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Fri Dec 24 02:02:17 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 24 Dec 2010 01:02:17 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293152537.28.0.908497471998.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101224.zip is a new version of the regex module.

Case-insensitive matching is now faster.

The matching functions and methods now accept a keyword argument to release the GIL during matching to enable other Python threads to run concurrently:

    matches = regex.findall(pattern, string, concurrent=True)

This should be used only when it's guaranteed that the string won't change during matching.

The GIL is always released when working on instances of the builtin (immutable) string classes because that's known to be safe.

----------
Added file: http://bugs.python.org/file20154/issue2636-20101224.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 24 02:36:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 01:36:59 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293154619.71.0.442698705237.issue2636@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to start reviewing this code, but dated zip files on a tracker make a very inefficient VC setup.  Would you consider exporting your development history to some public VC system?

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 24 03:17:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Dec 2010 02:17:33 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1293157053.46.0.101619615966.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Georg rejected this patch in Python 3.2:

"I did say I like the feature, but that was a) before beta 2
was released, now the next release is a release candidate, and b) this
thread showed that it is not at all obvious how the feature should look
like.  The fact that it isn't enabled by default also makes it seem less
attractive to me, but I understand the reasons why it shouldn't be on by
default.  Therefore, I'm not willing to make an exception here."

So I created a third party module on the Python cheese shop:
http://pypi.python.org/pypi/faulthandler/

The module works on Linux, FreeBSD and Windows with Python 2.6 through 3.2.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Fri Dec 24 03:41:59 2010
From: report at bugs.python.org (Andy Bailey)
Date: Fri, 24 Dec 2010 02:41:59 +0000
Subject: [issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for
	C++"
In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
Message-ID: <1293158519.07.0.399681450676.issue5755@psf.upfronthosting.co.za>


Changes by Andy Bailey <GooseYArd at gmail.com>:


----------
nosy: +GooseYArd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5755>
_______________________________________

From orsenthil at gmail.com  Fri Dec 24 03:45:51 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 24 Dec 2010 10:45:51 +0800
Subject: [issue4496] misleading comment in urllib2
In-Reply-To: <1293133981.83.0.385730959337.issue4496@psf.upfronthosting.co.za>
References: <1228252059.35.0.463804871486.issue4496@psf.upfronthosting.co.za>
	<1293133981.83.0.385730959337.issue4496@psf.upfronthosting.co.za>
Message-ID: <20101224024551.GH1911@rubuntu>

On Thu, Dec 23, 2010 at 07:53:01PM +0000, R. David Murray wrote:

> The sorting is based on a 'handler_order' attribute, by the way, and
> presumably does control the order in which they are applied.

Yes. Exactly.

From report at bugs.python.org  Fri Dec 24 03:46:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 24 Dec 2010 02:46:01 +0000
Subject: [issue4496] misleading comment in urllib2
In-Reply-To: <1293133981.83.0.385730959337.issue4496@psf.upfronthosting.co.za>
Message-ID: <20101224024551.GH1911@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Thu, Dec 23, 2010 at 07:53:01PM +0000, R. David Murray wrote:

> The sorting is based on a 'handler_order' attribute, by the way, and
> presumably does control the order in which they are applied.

Yes. Exactly.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4496>
_______________________________________

From report at bugs.python.org  Fri Dec 24 03:58:44 2010
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 24 Dec 2010 02:58:44 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293159524.87.0.66921386006.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

+1 on VC

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 24 04:32:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 03:32:05 +0000
Subject: [issue10767] Lib/test/crashers/README is out of date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Among other things, README says:

"""
Each test should have a link to the bug report:

        # http://python.org/sf/BUG#

"""

but the only such link is found in crashers/infinite_loop_re.py and points to a closed issue 1541697.

It looks like the purpose of Lib/test/crashers has changed from being a repository of outstanding bugs to a repository of crashers that are not considered to be bugs.

----------
assignee: docs at python
components: Documentation, Tests
messages: 124586
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Lib/test/crashers/README is out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10767>
_______________________________________

From report at bugs.python.org  Fri Dec 24 04:52:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 24 Dec 2010 03:52:19 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292977224.32.0.350996757442.issue10753@psf.upfronthosting.co.za>
Message-ID: <20101224035205.GA2701@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Wed, Dec 22, 2010 at 12:20:24AM +0000, R. David Murray wrote:
> Presumably all that is needed is to add ';' to 'safe' in the call
> that encodes PATH_INFO?

Well, that is what is required in order for the quote function call to
ignore it, but I am not sure what it the intention passing
/path;params as the PATH_INFO and how it is useful in wsgiref context.

Also there is this note in the PEP 333

Note that such a reconstructed URL may not be precisely the same URI
as requested by the client. Server rewrite rules, for example, may
have modified the client's originally requested URL to place it in a
canonical form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Fri Dec 24 05:05:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 24 Dec 2010 04:05:32 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1293163532.5.0.791572256264.issue3243@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

A mistake with Content-Length in the previous commit resolved in revision 87469.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Fri Dec 24 05:05:39 2010
From: report at bugs.python.org (Scott Rostrup)
Date: Fri, 24 Dec 2010 04:05:39 +0000
Subject: [issue8548] Building on CygWin 1.7: PATH_MAX redefined
In-Reply-To: <1272386591.01.0.834578637911.issue8548@psf.upfronthosting.co.za>
Message-ID: <1293163539.64.0.896848488564.issue8548@psf.upfronthosting.co.za>


Scott Rostrup <scott.rostrup at googlemail.com> added the comment:

I just encountered this error in python 3.1.3 on cygwin 1.7.
I used the same fix as jbinder.

Old Modules/main.c (line 13):

  #if defined(MS_WINDOWS) || defined(__CYGWIN__)
  #include <windows.h>
  #ifdef HAVE_FCNTL_H
  #include <fcntl.h>
  #define PATH_MAX MAXPATHLEN
  #endif
  #endif

I guess now cygwin is defining PATH_MAX, one possible fix with ifndef:

  #if defined(MS_WINDOWS) || defined(__CYGWIN__)
  #include <windows.h>
  #ifdef HAVE_FCNTL_H
  #include <fcntl.h>
  #ifndef
  #define PATH_MAX MAXPATHLEN
  #endif
  #endif
  #endif

This compiled and worked for me and it appears jbinder as well.

----------
nosy: +Scott.Rostrup
Added file: http://bugs.python.org/file20155/py_cygwin_build-3.1.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8548>
_______________________________________

From report at bugs.python.org  Fri Dec 24 05:13:27 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 24 Dec 2010 04:13:27 +0000
Subject: [issue10671] urllib2 redirect to another host doesn't work
In-Reply-To: <1291983407.25.0.106124609797.issue10671@psf.upfronthosting.co.za>
Message-ID: <1293164007.4.0.691367732314.issue10671@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Closing this as Invalid, because in the latest code, if the Host header is not explicitly specified by the request, then it is added to unredirected headers and if it explicitly specified by the request, then it is taken into account when the redirection happens.

Not sure how the bug reporter's case was.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10671>
_______________________________________

From orsenthil at gmail.com  Fri Dec 24 05:26:05 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 24 Dec 2010 12:26:05 +0800
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1292190747.18.0.879980664468.issue9893@psf.upfronthosting.co.za>
References: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
	<1292190747.18.0.879980664468.issue9893@psf.upfronthosting.co.za>
Message-ID: <20101224042605.GB2701@rubuntu>

On Sun, Dec 12, 2010 at 09:52:27PM +0000, Brett Cannon wrote:
> At this point I'm willing to either hand maintenance of the files
> over to someone else or to delete the files and shift what we point
> people at.

I think, just pointing to the script at vim.org location is a good
idea. It is maintained and updated by vimmers and we dont have to
bother about it. But a README would be helpful as what scripts we
"recommend", so that it sufficient to meet the style guidelines of
PEP8 and PEP7.

From report at bugs.python.org  Fri Dec 24 05:26:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 24 Dec 2010 04:26:22 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1292190747.18.0.879980664468.issue9893@psf.upfronthosting.co.za>
Message-ID: <20101224042605.GB2701@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Dec 12, 2010 at 09:52:27PM +0000, Brett Cannon wrote:
> At this point I'm willing to either hand maintenance of the files
> over to someone else or to delete the files and shift what we point
> people at.

I think, just pointing to the script at vim.org location is a good
idea. It is maintained and updated by vimmers and we dont have to
bother about it. But a README would be helpful as what scripts we
"recommend", so that it sufficient to meet the style guidelines of
PEP8 and PEP7.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Fri Dec 24 05:52:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Dec 2010 04:52:35 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1293166355.6.0.415234602962.issue10753@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, if the parameters aren't part of the path info, what are they part of?

They are passed as part of path info now, just incorrectly encoded.  I haven't found anything so far to make me think they belong anywhere else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Fri Dec 24 11:03:13 2010
From: report at bugs.python.org (Pierre Quentel)
Date: Fri, 24 Dec 2010 10:03:13 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

The scrolledtext example crashes with this message :

TypeError: unsupported operand type(s) for +: 'dict_keys' and 'dict_keys'

It works if keys() are converted to lists in line 33 :

methods = list(vars(Pack).keys()) + list(vars(Grid).keys()) + \list(vars(Place).keys())

Configuration : Python 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] on win32

----------
components: Tkinter
messages: 124593
nosy: quentel
priority: normal
severity: normal
status: open
title: Bug in scrolledtext
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Fri Dec 24 11:17:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Dec 2010 10:17:17 +0000
Subject: [issue10763] subprocess.communicate() doesn't close pipes on Windows
In-Reply-To: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>
Message-ID: <1293185837.65.0.67958972547.issue10763@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10763>
_______________________________________

From report at bugs.python.org  Fri Dec 24 11:54:46 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 24 Dec 2010 10:54:46 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293188086.8.0.129996803346.issue10768@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

It probably also works if | is used instead of +, because in 3.2 dict_proxy.keys() are a dict_keys, not a list. See issue10630 .

----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Fri Dec 24 13:29:27 2010
From: report at bugs.python.org (David Leonard)
Date: Fri, 24 Dec 2010 12:29:27 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1293193767.3.0.48706617638.issue10762@psf.upfronthosting.co.za>


David Leonard <d+python at adaptive-enterprises.com> added the comment:

Agree that the patches from issue 4804 and wrapping strftime() to catch the invalid_parameter call would fix this:

windbg trace:
0:000> k
Child-SP          RetAddr           Call Site
00000000`0021f328 000007fe`fdbb27cf ntdll!ZwTerminateProcess+0xa
00000000`0021f330 00000000`6ec24eec KERNELBASE!TerminateProcess+0x2f
00000000`0021f360 00000000`6ec24fc0 MSVCR90!invoke_watson+0x11c
00000000`0021f950 00000000`6ec11f5d MSVCR90!invalid_parameter+0x70
00000000`0021f990 00000000`6ec11fcd MSVCR90!Gettnames+0xebd
00000000`0021fa30 00000000`1e062e29 MSVCR90!strftime+0x15
00000000`0021fa70 00000000`1e0bff79 python27!PyTime_DoubleToTimet+0x5f9
00000000`0021fae0 00000000`1e10f084 python27!PyCFunction_Call+0x69
00000000`0021fb10 00000000`1e112834 python27!PyEval_GetGlobals+0x944
00000000`0021fb70 00000000`1e114039 python27!PyEval_EvalFrameEx+0x36a4
00000000`0021fc60 00000000`1e1140d9 python27!PyEval_EvalCodeEx+0x7e9
00000000`0021fd10 00000000`1e1400ca python27!PyEval_EvalCode+0x29
00000000`0021fd70 00000000`1e1417f6 python27!PyErr_Display+0x40a
00000000`0021fda0 00000000`1e14235e python27!PyRun_InteractiveOneFlags+0x1c6
00000000`0021fe10 00000000`1e1423d5 python27!PyRun_InteractiveLoopFlags+0xce
00000000`0021fe40 00000000`1e0443d9 python27!PyRun_AnyFileExFlags+0x45
00000000`0021fe70 00000000`1d00119e python27!Py_Main+0x8e9
00000000`0021ff30 00000000`777bf56d python+0x119e
00000000`0021ff60 00000000`779f3021 kernel32!BaseThreadInitThunk+0xd
00000000`0021ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10762>
_______________________________________

From report at bugs.python.org  Fri Dec 24 15:07:48 2010
From: report at bugs.python.org (Sven Brauch)
Date: Fri, 24 Dec 2010 14:07:48 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>


New submission from Sven Brauch <svenbrauch at googlemail.com>:

Hi,

I'm writing a python language support plugin for an IDE. I'm using the AST module to get information about the loaded source code, which works pretty well. However, in some cases, the information provided by the AST is simply not sufficient to do proper highlighting (or whatever); for example, 

class_instance.method(argument1.arg_attribute).attribute
class_instance.method(   argument1.    arg_attribute)    . attribute
and
class_instance.method(   argument1. \
                         arg_attribute)   \
                                   . attribute

produce exactly the same syntax tree, making it impossible to determine where e.g. "attribute" starts and ends. Although technically obviously correct, the information that the column offset for "attribute" is "0" is quite pointless.

It would really be great if there could be an additional attribute for Attribute Access nodes which tells me where the attribute access the node refers to *really* takes place, not just "column 0". :)
It would be even better if there was not only an offset, but also an "end" attribute providing information on where the node ends; that'd make this module way more useful, at least for me.

Thanks and best regards,
Sven

----------
components: Library (Lib)
messages: 124596
nosy: georg.brandl, scummos
priority: normal
severity: normal
status: open
title: ast: provide more useful range information
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Fri Dec 24 15:46:44 2010
From: report at bugs.python.org (Baptiste Carvello)
Date: Fri, 24 Dec 2010 14:46:44 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1293141315.66.0.109588617208.issue6011@psf.upfronthosting.co.za>
Message-ID: <4D14B22F.8050301@free.fr>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

Hello,

the patch solves the bug for me as well (using locale "C", the 
filesystem encoding is utf-8). However, I do not understand why the 
patch checks that the shebang line decodes with both utf-8 and the 
file's encoding. The shebang line is only used by the kernel to locate 
the interpreter, so none of these should matter. Or have I misuderstood 
the patch?

Cheers,
Baptiste

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Dec 24 16:38:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Dec 2010 15:38:42 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293205122.49.0.554216947941.issue10769@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Fri Dec 24 17:38:58 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 24 Dec 2010 16:38:58 +0000
Subject: [issue7198] Extraneous newlines with csv.writer on Windows
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1293208738.6.0.150713575702.issue7198@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

John,

The API for the open() builtin function has changed.  You should open
the output file with newline="" instead of using the default.  Take a
look at the documentation for open() and csv.reader:

    http://docs.python.org/py3k/library/functions.html?highlight=open#open
    http://docs.python.org/py3k/library/csv.html?highlight=csv.reader#csv.reader

Note the form of the open() call in the csv.reader example.  This one
snuck by me as well.  Python 3 underwent a lot of change in the I/O
subsystem.  This was one of them.  If changing the form of the open()
call doesn't fix the problem, let me know.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Fri Dec 24 19:36:26 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Dec 2010 18:36:26 +0000
Subject: [issue10767] Lib/test/crashers/README is out of date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293215786.51.0.790389572896.issue10767@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That's a fair assessment. A lot of the bugs that are easy to fix got closed out a couple of years back. The rest are (I think) considered too difficult and too marginal to worry about.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10767>
_______________________________________

From report at bugs.python.org  Fri Dec 24 19:49:54 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 24 Dec 2010 18:49:54 +0000
Subject: [issue10770] zipinfo - fix of a typo in the doc
In-Reply-To: <1293216594.75.0.298298210336.issue10770@psf.upfronthosting.co.za>
Message-ID: <1293216594.75.0.298298210336.issue10770@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello,
as reported[1] on python-doc, there's a typo in zipinfo doc.

[1] http://mail.python.org/pipermail/docs/2010-December/002526.html

The attached (trivial) patch fixes it; the file would also need a rewrap to 80th column.

Cheers,
Sandro

----------
assignee: sandro.tosi
components: Documentation
files: zipinfo_typo.patch
keywords: patch
messages: 124600
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: zipinfo - fix of a typo in the doc
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20156/zipinfo_typo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10770>
_______________________________________

From report at bugs.python.org  Fri Dec 24 20:02:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Dec 2010 19:02:53 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293217373.29.0.750131610482.issue10769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ISTM the whole point of an Abstract Syntax Tree is to express semantics while throwing away the syntax details.  The only reason any position information is kept is to support tracebacks and debugging.  

Perhaps the OP's request should changed to "add function to concrete parse trees to show structure while preserving all the input detail returned by tokenize."

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Fri Dec 24 20:11:44 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Dec 2010 19:11:44 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293217373.29.0.750131610482.issue10769@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=p_V=2K6gzJmttqy-fN0OK7G4cMr8yr022coZP@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/12/24 Raymond Hettinger <report at bugs.python.org>:
>
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> ISTM the whole point of an Abstract Syntax Tree is to express semantics while throwing away the syntax details. ?The only reason any position information is kept is to support tracebacks and debugging.

I agree for the most part. It's also nearly impossible to preserve all
the detail one would want in an *abstract* syntax tree.

>
> Perhaps the OP's request should changed to "add function to concrete parse trees to show structure while preserving all the input detail returned by tokenize."

If someone can comment on what that would look like...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Fri Dec 24 20:54:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Dec 2010 19:54:41 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293220481.98.0.847900282121.issue10769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If info fields are added, they need to be optional so that someone manipulating the tree (adding, rearranging, or removing nodes) doesn't have an additional burden of supplying this info before compiling into an executable code object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:02:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Dec 2010 20:02:04 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293220924.24.0.954909313232.issue10768@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Where is this example?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:15:36 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 24 Dec 2010 20:15:36 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293221736.73.0.383188231487.issue10768@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I don't think, that this is in an example (but probably there is an example somewhere, that crashes because of this). I found the code in Lib/tkinter/scrolledtext.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:20:35 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 24 Dec 2010 20:20:35 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1293222035.18.0.918260364542.issue10626@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Sorry for being AWOL for so long. Attached is a patch that doesn't install a handler and checks stderr for the exception output. Unfortunately, it looks like the logging tests are still messing things up:

./python.exe -m test test_concurrent_futures test_concurrent_futures
[1/2] test_concurrent_futures
[2/2] test_concurrent_futures
All 2 tests OK.

% ./python.exe -m test test_concurrent_futures test_logging test_concurrent_futures
[1/3] test_concurrent_futures
[2/3] test_logging
[3/3] test_concurrent_futures
test test_concurrent_futures failed -- Traceback (most recent call last):
  File "/home/bquinlan/shared/py3k/Lib/test/test_concurrent_futures.py", line 642, in test_done_callback_raises
    self.assertIn('Exception: doh!', stderr.getvalue())
AssertionError: 'Exception: doh!' not found in ''

2 tests OK.
1 test failed:
    test_concurrent_futures

----------
Added file: http://bugs.python.org/file20157/logging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:31:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 20:31:57 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1293222717.59.0.338854473539.issue9090@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 is closed except for security fixes, which this does not seem to be. If the problem is in 2.7, then it potentially could be fixed there, but with the same caveats. I will let Antoine reclose if he thinks appropriate.

----------
nosy: +terry.reedy
stage: committed/rejected -> patch review
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:36:32 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 20:36:32 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1293222992.03.0.544371594728.issue10733@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Mitchell: 2.6 is closed to revision except for security issues

----------
nosy: +terry.reedy
resolution: wont fix -> 
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:44:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Dec 2010 20:44:56 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293223496.05.0.0439854837789.issue10768@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: docs at python -> 
components:  -Documentation
keywords: +easy
nosy:  -docs at python
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Fri Dec 24 21:59:16 2010
From: report at bugs.python.org (Sven Brauch)
Date: Fri, 24 Dec 2010 20:59:16 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293224356.5.0.372026911653.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Hi,

well, but you have to agree that there is no point in setting a correct column offset for bar in 
foo[bar] (it's correctly set to 4 here!)
and
foo(bar)
but not for
foo.bar (there's no information provided here)
For me, this looks like it was just done the easiest way -- which is okay, of course, but is not a valid reason not to change it now.
It's also not that there's fifty things missing to make it fully functional for the purpose of highlighting / analyzing the code, this is about the only one. :)

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Fri Dec 24 22:21:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 21:21:34 +0000
Subject: [issue10738] webbrowser.py bug with Opera on Linux
In-Reply-To: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>
Message-ID: <1293225694.73.0.965575358692.issue10738@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

According to the linked doc, Opera has '-noraise' but not '-raise' as a command line option (to not raise window when receiving remote commands).

It does have '"raise()"' (with quotes and parens, but not "noraise()") as a remote command following the '-remote' command line option to be sent to another Opera window. I suspect this as the reason for the apparently invalid 
raise_opts = ["", "-raise"]

>From the usage of raise_opts in UnixBrowser._invoke, which concatenates one of the entries, if not "", to self.name, I am pretty sure the command line form is what is wanted and that the proposed
raise_opts = ["-noraise", ""]
is correct.

Attached patch also removes a few blank lines to make entries for different browsers consistent.

Georg, if you agree, I will commit the change and backport.

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> commit review
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20158/zweb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10738>
_______________________________________

From report at bugs.python.org  Fri Dec 24 22:38:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 21:38:52 +0000
Subject: [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1293226732.07.0.336842631359.issue10742@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with addition. Patch look OK to my limited .rst knowledge.

To be more parallel to the other entries, the text might say
"A bool indicating whether ..."

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10742>
_______________________________________

From report at bugs.python.org  Fri Dec 24 22:48:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 21:48:33 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1293227313.39.0.497383391831.issue10756@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Fri Dec 24 22:54:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 21:54:48 +0000
Subject: [issue10757] zipfile.write, arcname should be bytestring
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293227688.15.0.347196510976.issue10757@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +aimacintyre
stage:  -> unit test needed
type: compile error -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:03:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 22:03:49 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1293228229.0.0.512056630012.issue10762@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified problem with 3.2b1 on 32-bit winxp machine.
IDLE restarts after pythonw crashes.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10762>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:07:51 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 24 Dec 2010 22:07:51 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1293228471.76.0.198946567054.issue10737@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

What's the best way for me to test this? The problem occurs on a Windows-only code path but there is not enough information for me to debug it.

Should I check-in some additional diagnostics, wait for the buildbot to run, collect my data and then rollback my change?

Or can I run code on the buildbot directly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10737>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:26:57 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 24 Dec 2010 22:26:57 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293229617.82.0.8146946058.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've been trying to push the history to Launchpad, completely without success; it just won't authenticate (no such account, even though I can log in!).

I doubt that the history would be much use to you anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:27:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Dec 2010 22:27:43 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1293229663.01.0.202245190324.issue10737@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You can create a branch, checkin to that branch, then specify that a specific buildbot runs your branch. See the "force build" page of a build slave.

Additionally, I can give you access to my build slave, the Windows Server 2008 one, but that may take a few days due to the holiday weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10737>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:28:43 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Fri, 24 Dec 2010 22:28:43 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1293229723.07.0.132178416911.issue9709@psf.upfronthosting.co.za>


Thorsten Behrens <sbehrens at gmx.li> added the comment:

Thank you for that patch, Stefan. I am currently tinkering with bringing pycrypto to 3.x and ran into this issue. initfunc2.patch resolves the issue on Win7-64, python31-64.

I don't feel comfortable releasing code that requires the user to manually patch Python to build. What are my options here? Go back to void instead of PyMODINIT_FUNC? Is there aught else I can do to make sure pycrypto will build well "in the wild"?

----------
nosy: +thorsten.behrens

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:35:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 22:35:34 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za>
Message-ID: <1293230134.14.0.694739639627.issue10733@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:38:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Dec 2010 22:38:59 +0000
Subject: [issue1693546] email.Message set_param rfc2231 encoding incorrect
Message-ID: <1293230339.47.0.908532042285.issue1693546@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, I was wrong.  This would only be an issue when a parameter's value is changed, and at that point we should be producing correctly (un)quoted values no matter what the original quoting of the individual value was.

So I've applied the patch in r87479.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693546>
_______________________________________

From report at bugs.python.org  Fri Dec 24 23:39:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 22:39:28 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293230368.7.0.818197233146.issue10768@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since 'methods' is converted to a set in the next line, there is no need for lists. Instead, use | and delete the conversion.
  methods = vars(Pack).keys() + vars(Grid).keys() + vars(Place).keys()
  methods = set(methods).difference(text_meths)
becomes
  methods = vars(Pack).keys() | vars(Grid).keys() | vars(Place).keys()
  methods = methods.difference(text_meths)

Now I am a little puzzled why this does not fail (3.2b1, winxp):
>>> from tkinter.scrolledtext import ScrolledText
>>> s = ScrolledText()
>>> s
<tkinter.scrolledtext.ScrolledText object at 0x00F6CF70>

On the other hand, this fails elsewhere:
>>> from tkinter.scrolledtext import example
>>> example()
Traceback (most recent call last):
  File "<pyshell#34>", line 1, in <module>
    example()
  File "C:\Programs\Python32\lib\tkinter\scrolledtext.py", line 49, in example
    stext.insert(END, __main__.__doc__)
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 2970, in insert
    self.tk.call((self._w, 'insert', index, chars) + args)
_tkinter.TclError: wrong # args: should be ".16421456.16190896 insert index chars ?tagList chars tagList ...?"

----------
nosy: +gpolo, terry.reedy
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Sat Dec 25 00:06:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 23:06:42 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293232002.82.0.310127265771.issue10769@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A request limited only to fixing the current field for attribute may get more traction than a request for a new field. Can you dig into to code to get any idea why the difference between attributes versus indexes and parameters?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 00:17:41 2010
From: report at bugs.python.org (Sven Brauch)
Date: Fri, 24 Dec 2010 23:17:41 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293232661.61.0.321547337339.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Hi Terry,

well, the current behaviour is... logical in some way, as it says "the whole expression which accesses an attribute starts at column 0", i.e. it's easy to understand why it's done like this. It just turns out that this is pretty useless...

I'll try to find out what changes would be needed in the code to make the col_offset attribute useful in this case.

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 00:53:29 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 24 Dec 2010 23:53:29 +0000
Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on
	Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1293234809.37.0.255830415462.issue7334@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Florent, any chance of signing off on this for 3.2? I was waiting for the patch to go through your authorized elementtree fork

----------
assignee: pjenvey -> flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________

From report at bugs.python.org  Sat Dec 25 00:56:03 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 24 Dec 2010 23:56:03 +0000
Subject: [issue10737] test_concurrent_futures failure on Windows
In-Reply-To: <1292765565.27.0.231692660703.issue10737@psf.upfronthosting.co.za>
Message-ID: <1293234963.02.0.243592609253.issue10737@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

I'm good, thanks Brian C.

<br/>

It looks like SetEvent is failing with ERROR_INVALID_HANDLE.
CRITICAL:root:SetEvent(2044) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(2064) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(2220) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(1576) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(2284) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(2168) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(2264) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(1588) failed with 0, GetLastError() = 6
CRITICAL:root:SetEvent(2240) failed with 0, GetLastError() = 6

Now to figure out why...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10737>
_______________________________________

From report at bugs.python.org  Sat Dec 25 01:34:26 2010
From: report at bugs.python.org (Sven Brauch)
Date: Sat, 25 Dec 2010 00:34:26 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293237266.52.0.898826142926.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Hi,

I found the reason for this behavior in the code now, it's in Python/ast.c, lines 1745 and 1746 in ast_for_power():

        tmp->lineno = e->lineno;
        tmp->col_offset = e->col_offset;

Here, the range information for the individual attributes (which is correctly set before!) is being discarded and replaced by the useless information from the expression ast.
I don't see any reason for this, is there one? :)

Removing those two lines doesn't seem to break anything and sets ranges correctly.

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 01:51:31 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Dec 2010 00:51:31 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293237266.52.0.898826142926.issue10769@psf.upfronthosting.co.za>
Message-ID: <AANLkTimp6TddreQQ0hJ3TscLRdAZ8WjOxgguP1Q1hzog@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/12/24 Sven Brauch <report at bugs.python.org>:
>
> Sven Brauch <svenbrauch at googlemail.com> added the comment:
>
> Hi,
>
> I found the reason for this behavior in the code now, it's in Python/ast.c, lines 1745 and 1746 in ast_for_power():
>
> ? ? ? ?tmp->lineno = e->lineno;
> ? ? ? ?tmp->col_offset = e->col_offset;
>
> Here, the range information for the individual attributes (which is correctly set before!) is being discarded and replaced by the useless information from the expression ast.
> I don't see any reason for this, is there one? :)
>
> Removing those two lines doesn't seem to break anything and sets ranges correctly.

The ranges are correct. They just aren't what you want. The attribute
starts at the beginning of the power, not the ".".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 02:27:17 2010
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 25 Dec 2010 01:27:17 +0000
Subject: [issue10733] plistlib rejects strings containing control characters
In-Reply-To: <1293222992.03.0.544371594728.issue10733@psf.upfronthosting.co.za>
Message-ID: <802DC278-596F-4E72-A31A-C7339B9692B6@acm.org>


Mitchell Model <mlm at acm.org> added the comment:

Thanks for letting me know (and with a personalized message, yet!). I wasn't paying attention -- i verified that the problem exists in 2.7 and 3.1 and I just dragged 3.1 down to 2.6. Although I've been working furiously in Python for the past six months, I haven't been writing or teaching so I haven't been combing the documentation or testing examples or using obscure or forgotten features, which together are the source of nearly all my bug reports. So I just automatically did what I used to do. I understand the issue and difference; I just didn't realize 2.6 was closed -- I didn't really mean that this should be fixed in anything other than the current or even next release of anything. 
On Dec 24, 2010, at 3:36 PM, Terry J. Reedy wrote:

> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Mitchell: 2.6 is closed to revision except for security issues
> 
> ----------
> nosy: +terry.reedy
> resolution: wont fix -> 
> versions: +Python 3.2 -Python 2.6
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10733>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10733>
_______________________________________

From report at bugs.python.org  Sat Dec 25 02:39:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Dec 2010 01:39:00 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293241140.7.0.932421367535.issue2636@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I suspect it would help if there are more changes, though.

I believe that to push to launchpad you have to upload an ssh key.  Not sure why you'd get "no such account", though.  Barry would probably know :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Dec 25 02:48:37 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 25 Dec 2010 01:48:37 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293241717.97.0.405213700814.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It does have an SSH key. It's probably something simple that I'm missing.

I think that the only change I'm likely to make is to a support script I use; it currently uses hard-coded paths, etc, to do its magic. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Dec 25 04:54:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Dec 2010 03:54:28 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293249268.21.0.360400601731.issue5258@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, I think it is a good idea for site.py to issue error messages and continue on when it is processing files that don't come from the python distribution itself (such as pth files).  However, I think just printing the error message is not going to provide enough info.  For example the error in this issue would produce something like:

   TypeError: embedded NUL character

Which wouldn't be much of a clue as to what went wrong.  Likewise the case of a pth file containing a like this:

    import foo)bar

This would result in an error message like this:

    SyntaxError: invalid syntax

This seems fine at first glance, but what if the pth file is:

    import foo

and foo.py is:

     foo)bar

We get the *same* error message, but the pth file itself is syntactically correct.

So, I think it is better to print the traceback, even if it results in extra info (lines from the addpackage routine itself).  Attached is a patch that takes this approach.  I locate this code in addpackage itself so that I can get the line number from the pth file for the error message, further localizing it.  And I wrap all of the code that I think could throw errors due to bad pth files, but only that code.

Note that both of these patches also address issue 10642, so I'm going to make this a superseder for that issue.

If you like this approach, Georg, then we just need unit tests :)

----------
stage:  -> patch review
Added file: http://bugs.python.org/file20159/site_pth_exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sat Dec 25 05:00:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Dec 2010 04:00:31 +0000
Subject: [issue10642] Improve the error message of addpackage() (site.py) for
	defective .pth file
In-Reply-To: <1291692920.89.0.675754694355.issue10642@psf.upfronthosting.co.za>
Message-ID: <1293249631.1.0.347635407137.issue10642@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Georg posted a patch to issue 5258 that would "fix" this.  I've posted a counter proposal that would give more info.  We're proposing to simply write to stderr and then continue.  With either patch this issue would be fixed, so I'm making that issue a superseder for this one.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> addpackage in site.py fails hard on badly formed .pth files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10642>
_______________________________________

From report at bugs.python.org  Sat Dec 25 05:00:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Dec 2010 04:00:56 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293249656.8.0.646305797879.issue5258@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +Arfrever, dwr2, eric.araujo, haypo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sat Dec 25 06:05:54 2010
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sat, 25 Dec 2010 05:05:54 +0000
Subject: [issue10771] descriptor protocol documentation has two different
	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

In trunk/Doc/reference/datamodel.rst , under _Implementing Descriptors_, the documentation states: 

`The following methods only apply when an instance of the class containing the method (a so-called *descriptor* class) appears in the class dictionary of another new-style class, known as the *owner* class. [...]`

Immediately below, in the documentation for __get__, it says, `*owner* is always the owner class [...]`.

These two uses of "the owner class" are incompatible, because there is only one class which matches the first use: the class where the descriptor was initially assigned to a class attribute; however, for the second use, any descendant class may be called "the owner class". This is demonstrated in the attached doctest file.

It is kind of hard to create a better definition for "owner" as used in `__get__`, though. It can't be said to be the class with the descriptor in its class dict, because it can be present in the class dict of some class in the MRO of the owner. It can't be said to be an attribute, because it has to be in a class dict of an ancestor node.

It might be possible to change the definition to call the owner class something like, "the class from which the descriptor was invoked", and if that isn't clear enough, provide examples (TypeDescriptor from the attached doctest file might work as an example); however, this would involve reworking the structure of the paragraph substantially. I personally would prefer this option. The paragraph is already badly structured; for example, it defines two terms in a single and rather complex sentence, and should probably be split up into a list of definitions rather than an explanatory jumble paragraph. In addition, this paragraph is the only place in the documentation where this idea of "the owner class" is used in this way. In the descriptions of the descriptor protocol methods below it, "the owner class" always refers to the class from which the attribute was accessed, or the type from which an instance had the attribute accessed.

Alternatively, it could be simpler to replace all references below from "the owner class" to "any class with the owner class in the MRO".

----------
assignee: docs at python
components: Documentation
files: descriptor.py.doctest
messages: 124630
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: descriptor protocol documentation has two different definitions of "owner" class
versions: Python 2.7
Added file: http://bugs.python.org/file20160/descriptor.py.doctest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10771>
_______________________________________

From report at bugs.python.org  Sat Dec 25 07:52:09 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 25 Dec 2010 06:52:09 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1293259929.36.0.886396962828.issue10576@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well, the idea is good and it did cross my mind.  Particularly it could be useful for performance sensitive applications.
However it complicates things.
1) If a GC is rejected, when do we make the next attempt?
2) If a callback cancels GC, then what about the other callbacks that have already been called?  They would need to get some "canceled" call.  But this is ok, I suppose.

Since we have already passed the beta 2, I'll see if I can come up with a simple change, particularly if we don't descend into some infinite loop wrt. 1) above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Sat Dec 25 09:35:33 2010
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 25 Dec 2010 08:35:33 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293220924.24.0.954909313232.issue10768@psf.upfronthosting.co.za>
Message-ID: <AANLkTinBrhYGktgERCA0-1=jnpQ2j6GemWL2tCKvhnqO@mail.gmail.com>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

The function example(), line 44 of the module
- Pierre

2010/12/24 R. David Murray <report at bugs.python.org>

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Where is this example?
>
> ----------
> assignee:  -> docs at python
> components: +Documentation
> nosy: +docs at python, r.david.murray
> type: crash -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10768>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20161/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________
-------------- next part --------------
The function example(), line 44 of the module<br>- Pierre<br><br><div class="gmail_quote">2010/12/24 R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
Where is this example?<br>
<br>
----------<br>
assignee: ??-&gt; docs at python<br>
components: +Documentation<br>
nosy: +docs at python, r.david.murray<br>
type: crash -&gt; behavior<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/issue10768" target="_blank">http://bugs.python.org/issue10768</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sat Dec 25 11:49:50 2010
From: report at bugs.python.org (Sven Brauch)
Date: Sat, 25 Dec 2010 10:49:50 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293274190.95.0.354180098598.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Hi,

I agree that the current behavior is not wrong or such. It's just entirely useless.
For all the other types of subscripts, such as a[b][c][d] or a(b)(c)(d), the ranges of the actual subscript ASTs are also nulled, but there's an additional Name (or whatever) AST created for b, c, and d which contains their ranges. Why isn't it like this for attributes?

I also don't really see a reason why those ranges shouldn't be changed for all possible cases (subscript / call / attribute). It will contain more information while not taking any more memory or such, and it will be more intuitive. You can still get the information on where the expression starts by going up the chain to the next Expression AST node, which seems much more logical to me than storing this -- rarely useful -- information redundantly in maybe dozens of nodes. After all, the ast module is meant for "end users" to base applications on it, isn't it?

Otherwise, you should at least be consistent and remove that range information from the tree completely, because there's absolutely *no* case in which it would ever be useful (at least I cannot think of one).

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 12:43:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Dec 2010 11:43:10 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293277390.4.0.515592819828.issue5258@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Your patch is indeed better than mine, but I think the try-except in addsitedir() is not needed anymore?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sat Dec 25 14:15:28 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Dec 2010 13:15:28 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
In-Reply-To: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>
Message-ID: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi,
with the attached patch (quite easy honestly ;)) we can generate an EPUB.

I don't have a real e-book reader to test it on, but I used calibre (and its viewer) and the file is usable, and the cross-reference links works just fine; there are some CSS effects that are not shown (like the color in some boxes, like See also sections and so), but at least we have something to work with :)

What do you think would be the next steps?

Cheers,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
stage:  -> patch review
Added file: http://bugs.python.org/file20162/issue10130-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Sat Dec 25 15:29:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Dec 2010 14:29:25 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293274190.95.0.354180098598.issue10769@psf.upfronthosting.co.za>
Message-ID: <AANLkTikV9koeRhwqR_SzPeWzECCNr2+CTximyg4u24-p@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/12/25 Sven Brauch <report at bugs.python.org>:
>
> Sven Brauch <svenbrauch at googlemail.com> added the comment:
>
> Hi,
>
> I agree that the current behavior is not wrong or such. It's just entirely useless.
> For all the other types of subscripts, such as a[b][c][d] or a(b)(c)(d), the ranges of the actual subscript ASTs are also nulled, but there's an additional Name (or whatever) AST created for b, c, and d which contains their ranges. Why isn't it like this for attributes?

Because those can take any Python expression. Attributes only ever take a name.

>
> I also don't really see a reason why those ranges shouldn't be changed for all possible cases (subscript / call / attribute). It will contain more information while not taking any more memory or such, and it will be more intuitive. You can still get the information on where the expression starts by going up the chain to the next Expression AST node, which seems much more logical to me than storing this -- rarely useful -- information redundantly in maybe dozens of nodes. After all, the ast module is meant for "end users" to base applications on it, isn't it?

Expr is just a container node. It's not supposed to store extra information.

>
> Otherwise, you should at least be consistent and remove that range information from the tree completely, because there's absolutely *no* case in which it would ever be useful (at least I cannot think of one).

That's not the case here:

x = foo.blah

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 15:43:58 2010
From: report at bugs.python.org (Sven Brauch)
Date: Sat, 25 Dec 2010 14:43:58 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293288238.01.0.93876038413.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Well, weather it's supposed to or not, it *does* contain the line number information:
<ExprAst lineno="1" col_offset="0">
For your example, the AST for "foo" tells you the offset for foo. If you want to know the offset (well, "offset") for blah, why not look at foo? Currently, the information is just copied from foo to blah.

Anyway, I'd like to get away from this abstract discussion which is not likely to yield a result... is there any reason not to do it like I suggested other than the philosophical "it's wrong"? Or don't you agree that the information given this way would be more useful?

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 15:53:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Dec 2010 14:53:12 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293288792.58.0.545955708728.issue5258@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, I forgot to delete that bit when I realized it could all be done in one place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sat Dec 25 16:19:17 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Dec 2010 15:19:17 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293288238.01.0.93876038413.issue10769@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=1v2x_4pKqx-mZFJvXiOWgvWyE3uGQXPh6zy9d@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/12/25 Sven Brauch <report at bugs.python.org>:
>
> Sven Brauch <svenbrauch at googlemail.com> added the comment:
>
> Well, weather it's supposed to or not, it *does* contain the line number information:
> <ExprAst lineno="1" col_offset="0">
> For your example, the AST for "foo" tells you the offset for foo. If you want to know the offset (well, "offset") for blah, why not look at foo? Currently, the information is just copied from foo to blah.

What if it's like this, though?

x = (    foo).blah

>
> Anyway, I'd like to get away from this abstract discussion which is not likely to yield a result... is there any reason not to do it like I suggested other than the philosophical "it's wrong"? Or don't you agree that the information given this way would be more useful?

It wouldn't be any more useful than it is now. I don't think it's
reasonably possible to preserve every last obscure formatting in ast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 16:47:03 2010
From: report at bugs.python.org (Sven Brauch)
Date: Sat, 25 Dec 2010 15:47:03 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293292023.24.0.426095569932.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Then you'd get the point where foo starts instead of the location of the opening brace. Sounds good for me.

Also, I already said that, with the change I proposed, I do not see any case where relevant information would be lost.

Your argument that it would not be any more useful than now is simply invalid, because I got an application here which would work with, but not without the change, and I didn't yet see one for the other side.

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 17:37:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Dec 2010 16:37:07 +0000
Subject: [issue10757] zipfile.write, arcname should be bytestring
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293295027.59.0.0932649866073.issue10757@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also msg79724 of issue 4871.  From looking at the code it appears that the filename must be a string, and if it contains only ASCII characters it is entered as ascii, while if it contains non-ascii it is encoded to utf-8 and the appropriate flag bits set in the archive to indicate this (I know nothing about the archive format, by the way, I'm just looking at the code).

So, in reverse of issue 4871, it appears that in this case the API should reject bytes input with an appropriate error message.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Sat Dec 25 17:47:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Dec 2010 16:47:41 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293295661.43.0.617755494506.issue10769@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

FWIW, I find the current behavior for attributes to be surprising, to the point where at first glance it almost looks like a bug. Which is to say, I would have expected 'col' to point to the first non-whitespace column after the '.'. If there are multiple attributes, a.b.c.d, then to me, each node should point to its appropriate place, just as with a[b][c].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sat Dec 25 18:20:23 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 25 Dec 2010 17:20:23 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1293297623.07.0.705471898091.issue10756@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

It's because `PyErr_Fetch()` which is used in `atexit_callfuncs()` can return an unnormalized exception (e.g. if the exception is set with `PyErr_SetString()`. "value" is then a string). A simple call to `PyErr_NormalizeException()` fixes this issue.

Attached is a patch which fixes the issue and adds a test for it. I used exactly the same code ("1 / 0") to raise the exception, as I don't know if there is some clean way to raise an unnormalized exception.

----------
keywords: +patch
nosy: +Trundle
Added file: http://bugs.python.org/file20163/issue10756_normalize_exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sat Dec 25 19:44:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Dec 2010 18:44:54 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1293302694.32.0.222707329472.issue4391@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20152/fix-optparse-ngettext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sat Dec 25 19:47:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Dec 2010 18:47:42 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1293302862.17.0.431881335749.issue4391@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Previous version was incomplete.

----------
nosy: +gward
Added file: http://bugs.python.org/file20164/fix-optparse-ngettext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Sat Dec 25 20:26:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Dec 2010 19:26:26 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
In-Reply-To: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>
Message-ID: <1293305186.5.0.310062349944.issue10130@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The next step is publishing these epubs and waiting for the resulting flood of bug reports :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Sat Dec 25 20:37:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Dec 2010 19:37:51 +0000
Subject: [issue9239] zipfile: truncating comment can corrupt the zipfile
In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za>
Message-ID: <1293305871.64.0.585979552867.issue9239@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: aimacintyre -> alanmcintyre
nosy: +alanmcintyre -aimacintyre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9239>
_______________________________________

From report at bugs.python.org  Sat Dec 25 22:46:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Dec 2010 21:46:49 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <4D14B22F.8050301@free.fr>
Message-ID: <1293313640.21272.173.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le vendredi 24 d?cembre 2010 ? 14:46 +0000, Baptiste Carvello a ?crit :
> the patch solves the bug for me as well (using locale "C", the 
> filesystem encoding is utf-8). However, I do not understand why the 
> patch checks that the shebang line decodes with both utf-8 and the 
> file's encoding. The shebang line is only used by the kernel to locate 
> the interpreter, so none of these should matter. Or have I misuderstood 
> the patch?

The shebang is read by 3 different functions:

 a) the shell reads the first line: if it starts with "#!", it's a
shebang: read the command and options and execute it
 b) Python searchs a "#cookie:xxx" pattern in the first or the second
line using a binary parser
 c) Python reads the file using the Python encoding: encoding written in
the #coding:xxx header or UTF-8 by default

(a) The shell reads the file as a binary file, it doesn't care of the
encoding. It reads byte strings and pass them to the kernel.

(b) The parser starts with the default encoding, UTF-8. Even if the file
encoding is not UTF-8, all lines (Python only checks the cookie in the
first or the second line) before #coding:xxx cookie are read in UTF-8.
The shebang have to be written to the first line, so the cookie cannot
be written before the shebang => the shebang have to be decodable from
UTF-8

(b) If the file encoding is not UTF-8, a #cookie:xxx is used and the
whole file (including the shebang) have to be decodable from this
encoding => the shebang have to be decodable from the file encoding

So the shebang have to be decodable from UTF-8 and from the file
encoding.

I should maybe add a comment about that in the patch.

Example of (b) issue:
---
$ ./build/scripts-3.2/2to3
  File "./build/scripts-3.2/2to3", line 1
SyntaxError: Non-UTF-8 code starting with '\xff' in
file ./build/scripts-3.2/2to3 on line 1, but no encoding declared; see
http://python.org/dev/peps/pep-0263/ for details
---
The shebang is b'#!/home/haypo/tmp/py3k\xff/bin/python3.2\n', my locale
encoding is UTF-8 and the file encoding has no encoding cookie (it is
encoded to UTF-8).

--

copy_script.patch fixes an issue if the configure prefix is not ASCII
(especially if the prefix is not decodable from UTF-8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Dec 25 23:16:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Dec 2010 22:16:31 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1293315391.0.0.75519597072.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update copy_script patch: add comments to explain why the shebang have to be decodable from UTF-8 and from the script encoding.

----------
Added file: http://bugs.python.org/file20165/copy_script-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Dec 25 23:35:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Dec 2010 22:35:28 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1293316528.94.0.663673818203.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Baptiste: I meant that I couldn?t reproduce the bug, not that the patch had solved it.

Victor: Your patch uses os.fsencode, so porting to distutils2 won?t be easy.  Tarek and I have instated this policy http://wiki.python.org/moin/Distutils/FixingBugs to make sure we don?t have to reopen 50 bugs when distutils2 gets into the stdlib.

d2 has to stay compatible with 2.4-2.7, and 3.1-3.2 in a near future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Dec 25 23:43:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Dec 2010 22:43:45 +0000
Subject: [issue10763] subprocess.communicate() doesn't close pipes on Windows
In-Reply-To: <1293105568.33.0.901642583653.issue10763@psf.upfronthosting.co.za>
Message-ID: <1293317025.78.0.462930421665.issue10763@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r87485 (Python 3.2).

I don't want to fix it in 2.7 or 3.1, because maybe someone relies on this bug and it's a minor bug :-) Reopen the issue if you would like a backport.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10763>
_______________________________________

From report at bugs.python.org  Sat Dec 25 23:56:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Dec 2010 22:56:52 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1293316528.94.0.663673818203.issue6011@psf.upfronthosting.co.za>
Message-ID: <1293317844.21272.195.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le samedi 25 d?cembre 2010 ? 22:35 +0000, ?ric Araujo a ?crit :
> Victor: Your patch uses os.fsencode, so porting to distutils2 won?t be
> easy.

In Python 3.1, you can replace name=os.fsencode(name) by
name=name.encode(sys.getfilesystemencoding(), 'surrogateescape'). The
mbcs codec doesn't support surrogateescape. In Python 3.2 it does now
raise an error (and so os.fsencode() uses strict error handler if the
encoding is mbcs), whereas Python 3.1 just ignores the error handler (it
uses 'ignore' to encode).

In Python 2, self.executable is already a byte string (you don't need
os.fsencode()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Dec 25 23:58:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Dec 2010 22:58:56 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1293317936.78.0.296332787544.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I suggest you wait for distutils2 to be 3.x-compatible and then adapt your patch to fix the bug when used with 3.2, keeping backward compat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Dec 25 23:59:35 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Dec 2010 22:59:35 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
In-Reply-To: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>
Message-ID: <1293317975.75.0.278312698231.issue10130@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

ah great, 'bugs-generator' is my middle name :)

If I got it right, I've prepared another patch to add the archives generation in Doc/makefile (for dist target) and then add them to the download page.

Just let me know if I missed something, I'm still learning

----------
Added file: http://bugs.python.org/file20166/issue10130_part2-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Sun Dec 26 00:09:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Dec 2010 23:09:41 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1293318581.59.0.740669368845.issue9893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?It is maintained and updated by vimmers and we dont have to bother about it? is trumped by ?I personally got tired of not having new keywords be recognized?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Sun Dec 26 02:33:04 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 26 Dec 2010 01:33:04 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

I actually noticed this while trying to free the -h option for my program. The actions not mentioned are count, help, and parsers. Also for nargs, '...' and 'A...' are not documented either in the Sphinx docs or the leading docstring for the Action class.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 124654
nosy: docs at python, ipatrol
priority: normal
severity: normal
status: open
title: Several actions for argparse arguments missing from docs
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Sun Dec 26 02:44:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:44:32 +0000
Subject: [issue10415] readline.insert_text documentation incomplete
In-Reply-To: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>
Message-ID: <1293327872.04.0.270109938828.issue10415@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Justin, thanks for the report and patch.  Would you like to turn your suggestion into a patch?  Guidelines are at http://www.python.org/dev/patches/

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10415>
_______________________________________

From report at bugs.python.org  Sun Dec 26 02:46:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:46:24 +0000
Subject: [issue1705393] Select() failure (race condition)
Message-ID: <1293327984.84.0.01993651827.issue1705393@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -BreamoreBoy
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705393>
_______________________________________

From report at bugs.python.org  Sun Dec 26 02:50:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:50:37 +0000
Subject: [issue7436] Define 'object with assignable attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1293328237.65.0.0464810881402.issue7436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?d have to be careful to distinguish attributes defined to be not assignable and CPython implementation details.  In the absence of a definition in the doc, there is a chicken-and-egg problem, so I think a patch would have to be discussed on python-dev to get answers from the language designers.

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7436>
_______________________________________

From report at bugs.python.org  Sun Dec 26 02:59:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:59:00 +0000
Subject: [issue7678] subprocess.Popen pipeline example code in the
	documentation is lacking
In-Reply-To: <1263245210.2.0.116487607425.issue7678@psf.upfronthosting.co.za>
Message-ID: <1293328740.75.0.204805336955.issue7678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As a non-expert user of subprocess, calling close before communicate seems strange to me.  Does the example code with a bug work if close is called after communicate?

In the 3.2 docs, we could update the example to use a with statement, unless it is deemed a distraction for this simple introductory section.

----------
nosy: +eric.araujo, gregory.p.smith -georg.brandl
stage:  -> needs patch
type:  -> 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/issue7678>
_______________________________________

From report at bugs.python.org  Sun Dec 26 03:11:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:11:08 +0000
Subject: [issue8648] The UTF-7 codec functions are undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1293329468.56.0.991585503848.issue8648@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, typo fixed in r83977.

----------
nosy: +eric.araujo
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8648>
_______________________________________

From report at bugs.python.org  Sun Dec 26 03:27:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:27:16 +0000
Subject: [issue9891] Minor doc typo at datamodel.rst: "list" -> "alist"
In-Reply-To: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>
Message-ID: <1293330436.36.0.455362062707.issue9891@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in r87486 (py3k), r87487 (3.1) and r87488 (2.7), thanks!

----------
nosy: +eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9891>
_______________________________________

From report at bugs.python.org  Sun Dec 26 03:32:23 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 26 Dec 2010 02:32:23 +0000
Subject: [issue9882] abspath from directory
In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>
Message-ID: <1293330743.13.0.0549329500828.issue9882@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Yes, but this seems to be rational particularly for emulating directory changes without actually doing so. Since relative paths can use .. it may not always be straightforward to do this. Applications include archivers, dependency checkers, patch tools, self-extractors, installers, file managers, sync managers, D/VCS systems, loggers, and anti-malware programs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9882>
_______________________________________

From report at bugs.python.org  Sun Dec 26 03:41:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:41:55 +0000
Subject: [issue3216] Scarce msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1293331315.94.0.263257601894.issue3216@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nonexistent parameter removed from the doc in r87489 and following.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3216>
_______________________________________

From report at bugs.python.org  Sun Dec 26 03:52:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:52:19 +0000
Subject: [issue9196] Improve docs for string interpolation "%s" re Unicode
	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1293331939.74.0.774086678048.issue9196@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure how much effort should be put into a patch here, considering that the horrible bytes/text confusion and implicit conversion should stop in Python 3, and %-formatting is mildly deprecated.  Ezio, what do you think?

Craig, could you attach your test_object class and test code?  I wonder if the mixed behavior is still present in 3.x.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Sun Dec 26 04:14:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 03:14:48 +0000
Subject: [issue9115] test_site: support for systems without unsetenv
In-Reply-To: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>
Message-ID: <1293333288.73.0.497033328307.issue9115@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached patch uses a copy of os.environ, like other tests already do.  Can you test it?

Also, is the lack of unsetenv a problem only for test_s_option?  If not, we should fix the test infrastructure, not each test.

----------
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20167/fix-9115.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9115>
_______________________________________

From report at bugs.python.org  Sun Dec 26 10:35:51 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 26 Dec 2010 09:35:51 +0000
Subject: [issue7436] Define 'object with assignable attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1293356151.98.0.974847301326.issue7436@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7436>
_______________________________________

From report at bugs.python.org  Sun Dec 26 11:49:20 2010
From: report at bugs.python.org (Craig McQueen)
Date: Sun, 26 Dec 2010 10:49:20 +0000
Subject: [issue9196] Improve docs for string interpolation "%s" re Unicode
	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1293360560.48.0.998569345569.issue9196@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I should be able to attach my test code. But it is at my work, and I'm on holidays for 2 more weeks. Sorry 'bout that!

I do assume that Python 3 greatly simplifies this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Sun Dec 26 13:46:25 2010
From: report at bugs.python.org (Sven Brauch)
Date: Sun, 26 Dec 2010 12:46:25 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293367585.59.0.17008691647.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Hi,

yeah Terry, that's exactly what most people whom I talked about this said (me too).

Anyway, here's the patch which -- in my opinion -- fixes this behavior:

--- python-orig/Python/ast.c 2010-10-19 03:22:07.000000000 +0200
+++ python-ast-fix/Python/ast.c 2010-12-26 13:25:48.000000000 +0100
@@ -1742,8 +1742,6 @@
         tmp = ast_for_trailer(c, ch, e);
         if (!tmp)
             return NULL;
-        tmp->lineno = e->lineno;
-        tmp->col_offset = e->col_offset;
         e = tmp;
     }
     if (TYPE(CHILD(n, NCH(n) - 1)) == factor) {

The offsets for "foo.bar.baz" before the patch:

[1, 0, <_ast.Attribute>]
[1, 0, <_ast.Attribute>, 'baz']
[1, 0, <_ast.Name>, 'bar']
[1, 0, 'foo']

... and after the patch:

[1, 0, <_ast.Attribute>]
[1, 7, <_ast.Attribute>, 'baz']
[1, 3, <_ast.Name>, 'bar']
[1, 0, 'foo']

It would really be great if that could be applied.

Best regards,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sun Dec 26 18:05:09 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Sun, 26 Dec 2010 17:05:09 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1293383109.83.0.0134973931287.issue10576@psf.upfronthosting.co.za>


Lukas Lueg <lukas.lueg at gmail.com> added the comment:

Collection may re-occur at any time, there is no promise to the callback code. However, the callback can disable the gc, preventing further collection.

I don't think we need the other callbacks to be informed. As the callbacks are worked down in the order they registered, whoever comes first is served first. Returning True from the callback is mereley a "I dont mind if gc happens now..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Sun Dec 26 18:05:45 2010
From: report at bugs.python.org (Felix Schwarz)
Date: Sun, 26 Dec 2010 17:05:45 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1293383145.5.0.721329626388.issue2504@psf.upfronthosting.co.za>


Changes by Felix Schwarz <felix.schwarz at web.de>:


----------
nosy: +Felix Schwarz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sun Dec 26 18:27:44 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Sun, 26 Dec 2010 17:27:44 +0000
Subject: [issue10773] "Building C and C++ Extensions on Windows" documentation
	shows 2.x way of initializing module
In-Reply-To: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>
Message-ID: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>


New submission from Thorsten Behrens <sbehrens at gmx.li>:

The documentation titled "Building C and C++ Extensions on Windows" at http://docs.python.org/py3k/extending/windows.html shows a Python 2.x way of handling static type object initializers, to whit:

>>
If your module creates a new type, you may have trouble with this line:

PyVarObject_HEAD_INIT(&PyType_Type, 0)

Static type object initializers in extension modules may cause compiles to fail with an error message like ?initializer not a constant?. This shows up when building DLL under MSVC. Change it to:

PyVarObject_HEAD_INIT(NULL, 0)

and add the following to the module initialization function:

MyObject_Type.ob_type = &PyType_Type;

>>

That last line will not function in Python 3.x. However, PyType_Ready will fill in the ob_type field if it is empty, if I understand PyType_Ready correctly. Therefore, the last few lines of this documentation snippet can become:

>>
and add the following to the module initialization function:

if (PyType_Ready(&MyObject_Type) < 0)
    return NULL;
>>

----------
assignee: docs at python
components: Documentation
messages: 124667
nosy: docs at python, thorsten.behrens
priority: normal
severity: normal
status: open
title: "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10773>
_______________________________________

From report at bugs.python.org  Sun Dec 26 18:43:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 17:43:33 +0000
Subject: [issue6720] multiprocessing logging
In-Reply-To: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
Message-ID: <1293385413.54.0.0897262691875.issue6720@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is either out of date (2.5 doesn?t get bugfixes any more) or invalid (concerns a backport of multiprocessing outside of the stdlib).

----------
nosy: +eric.araujo
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6720>
_______________________________________

From report at bugs.python.org  Sun Dec 26 18:51:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 17:51:56 +0000
Subject: [issue10774] test_logging leaks temp files
In-Reply-To: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>
Message-ID: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

After a test_logging run in 3.2, I get stray files in $TMP.  I think some test is not using the right mixin or addCleanup or tearDown.

Less importantly, some recently added docstrings produce unwanted output on the console (the method name is clear enough, the redundant docstring is redundant); attached output turns them into comments.

----------
assignee: vinay.sajip
components: Tests
files: test_logging-nits.diff
keywords: patch
messages: 124669
nosy: eric.araujo, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging leaks temp files
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20168/test_logging-nits.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10774>
_______________________________________

From report at bugs.python.org  Sun Dec 26 19:00:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 18:00:06 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1293386406.17.0.139518899837.issue10756@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.  I?d just move the raising function into the test method (no need to update the patch).

----------
nosy: +eric.araujo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sun Dec 26 19:00:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 18:00:11 +0000
Subject: [issue10770] zipinfo - fix of a typo in the doc
In-Reply-To: <1293216594.75.0.298298210336.issue10770@psf.upfronthosting.co.za>
Message-ID: <1293386411.94.0.765995706161.issue10770@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed, thanks.  Note that Georg and I follow the docs mailing list, so there is no need to open a report for each message.

----------
nosy: +eric.araujo
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10770>
_______________________________________

From report at bugs.python.org  Sun Dec 26 19:58:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Dec 2010 18:58:33 +0000
Subject: [issue10774] test_logging leaves temp files
In-Reply-To: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>
Message-ID: <1293389913.29.0.730596178689.issue10774@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
title: test_logging leaks temp files -> test_logging leaves temp files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10774>
_______________________________________

From report at bugs.python.org  Sun Dec 26 20:02:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 19:02:09 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293390129.47.0.948158872301.issue5258@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a revised patch with tests.

----------
Added file: http://bugs.python.org/file20169/site_pth_exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sun Dec 26 20:04:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Dec 2010 19:04:15 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1293390255.82.0.486522513206.issue10756@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sun Dec 26 20:14:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Dec 2010 19:14:29 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293390869.63.0.74638268359.issue5258@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sun Dec 26 20:19:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 19:19:03 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

assertRaises used as a method can't take a msg keyword argument because all args and keywords are passed to the callable.  But in context manager form it could, and this can be useful.  See, for example, issue 3583.

----------
keywords: easy
messages: 124675
nosy: michael.foord, r.david.murray, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: assertRaises as a context manager should accept a 'msg' keyword argument.
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Sun Dec 26 20:30:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 19:30:19 +0000
Subject: [issue3583] test_urllibnet.test_bad_address() fails when using OpenDNS
In-Reply-To: <1219008061.86.0.538682955954.issue3583@psf.upfronthosting.co.za>
Message-ID: <1293391819.77.0.431903797191.issue3583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the best we can do here is add a message explaining that the error may be due to a broken DNS server (one with a wildcard dns record for all non-existent top level domains).  However, assertRaises, even in context manager form, doesn't take a msg argument (yet).  I've opened an issue with a feature request to fix that and made it a dependency of this issue.

Note that the test uses a domain name ending in ".d", and for a while before that used '.invalid', so the test should not fail if the ISP is only capturing valid top level domains with wildcards, something that seems to be far more common than catching invalid domains.

----------
dependencies: +assertRaises as a context manager should accept a 'msg' keyword argument.
nosy: +r.david.murray
priority: normal -> low
stage: unit test needed -> needs patch
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3583>
_______________________________________

From report at bugs.python.org  Sun Dec 26 20:42:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 19:42:19 +0000
Subject: [issue6027] test_xmlrpc_net fails when the ISP returns "302 Found"
In-Reply-To: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za>
Message-ID: <1293392539.49.0.161234615481.issue6027@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

IMO there's no way to fix this.  I suggest closing it as invalid, since the problem is a buggy ISP DNS server, and the problem only occurs when time.xmlrpc.com is down.

The canonical fix to problems like this is to remove dependency on the external service, but that would presumably defeat the entire purpose of test_xmlrpc_net.  So one "fix" would be to delete this test entirely.  Which if we have mock-server xmlrpc tests, might not be out of the question as a solution.  Note that the second test in that file tests against the xmlrpc interface of our buildbot master, and that support has been formally removed by upstream and only restored by us...presumably at some point we'll drop support for it too, when it breaks too badly to be easily forward ported.

Since there was, if I remember correctly, an extended period when xmlrpc.com's time service was down, simply deleting this test file may in fact be the best move.

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6027>
_______________________________________

From report at bugs.python.org  Sun Dec 26 21:52:51 2010
From: report at bugs.python.org (John Machin)
Date: Sun, 26 Dec 2010 20:52:51 +0000
Subject: [issue7198] Extraneous newlines with csv.writer on Windows
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1293396771.67.0.157981030344.issue7198@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Skip, I'm WRITING, not reading.. Please read the 3.1 documentation for csv.writer. It does NOT mention newline='', and neither does the example. Please fix.

Other problems with the examples: (1) They encourage a bad habit (open inside the call to reader/writer); good practice is to retain the reference to the file handle (preferably with a "with" statement) so that it can be closed properly. (2) delimiter=' ' is very unrealistic.

The documentation for both 2.x and 3.x should be much more explicit about what is needed in open() for csv to work properly and portably:

2.x read: use mode='rb' -- otherwise fail on Windows
2.x write: use mode='wb' -- otherwise fail on Windows
3.x read: use newline='' -- otherwise fail unconditionally(?)
3.x write: use newline='' -- otherwise fail on Windows

The 2.7 documentation says """If csvfile is a file object, it must be opened with the 'b' flag on platforms where that makes a difference""" ... in my experience, people are left asking "what platforms? what difference?"; Windows should be mentioned explicitly.

----------
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Sun Dec 26 21:59:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Dec 2010 20:59:28 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293397168.19.0.553663758993.issue10769@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I suggest you mail python-dev or python-ideas. I find it more consistent as it stands now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sun Dec 26 22:17:07 2010
From: report at bugs.python.org (Sven Brauch)
Date: Sun, 26 Dec 2010 21:17:07 +0000
Subject: [issue10769] ast: provide more useful range information
In-Reply-To: <1293199668.93.0.710632978584.issue10769@psf.upfronthosting.co.za>
Message-ID: <1293398227.52.0.651917303959.issue10769@psf.upfronthosting.co.za>


Sven Brauch <svenbrauch at googlemail.com> added the comment:

Okay, thank you, I'm going to do that. :)

Bye,
Sven

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10769>
_______________________________________

From report at bugs.python.org  Sun Dec 26 23:30:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 22:30:05 +0000
Subject: [issue5258] addpackage in site.py fails hard on badly formed .pth
	files
In-Reply-To: <1234614964.94.0.514404315884.issue5258@psf.upfronthosting.co.za>
Message-ID: <1293402605.09.0.283577225659.issue5258@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r87497, 3.1 in r87499, and 2.7 in r87500.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5258>
_______________________________________

From report at bugs.python.org  Sun Dec 26 23:52:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 26 Dec 2010 22:52:16 +0000
Subject: [issue7198] Extraneous newlines with csv.writer on Windows
In-Reply-To: <1256422121.38.0.499052368843.issue7198@psf.upfronthosting.co.za>
Message-ID: <1293403936.42.0.735133057091.issue7198@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I'm reopening this as a doc issue, since currently the Python3 writer docs do not mention newline='', and it is indeed required on Windows.  John, would you care to suggest a doc patch?

I agree with Skip that "where it makes a difference" is more precise than specifically mentioning Windows, even if less useful in this context.  That is how the 'b' mode is documented in the open documentation.  To fix the problem with the CSV docs, the recommendation to use 'b' can simply be made unconditional, as it is for newline='' in python3.

----------
components: +Documentation
nosy: +r.david.murray
resolution: invalid -> 
stage:  -> needs patch
status: closed -> open
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7198>
_______________________________________

From report at bugs.python.org  Mon Dec 27 00:01:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 26 Dec 2010 23:01:03 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1293404463.41.0.559155036139.issue10296@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With a release build of python, I have a similar behavior on both 2.5 and 2.7; the messages are different though:
2.5: WindowsError: [Error -2147483645] One or more arguments are invalid.
2.7: WindowsError: exception: breakpoint encountered

And with both versions, a debug build (python_d.exe) triggers the JIT debugger. What do you get exactly?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10296>
_______________________________________

From report at bugs.python.org  Mon Dec 27 00:14:22 2010
From: report at bugs.python.org (Aaron Masover)
Date: Sun, 26 Dec 2010 23:14:22 +0000
Subject: [issue10776] os.utime returns an error on NTFS-3G partition
In-Reply-To: <1293405262.1.0.932340163478.issue10776@psf.upfronthosting.co.za>
Message-ID: <1293405262.1.0.932340163478.issue10776@psf.upfronthosting.co.za>


New submission from Aaron Masover <amasover at gmail.com>:

I'm working with Anki (http://ankisrs.net/) on a linux NTFS-3G partition. Anki requires access to modification times in order to handle its backup files. This works fine on my ext3 partition, but on an NTFS partition accessed with NTFS-3G an error is returned:

youlun at yinghuochong:/storage/??/anki/decks$ python -c 'import shutil,os; shutil.copyfile(u"\u6f22\u5b57.anki", "new.anki"); os.utime("new.anki", None)'
youlun at yinghuochong:/storage/??/anki/decks$ python -c 'import shutil,os; shutil.copyfile(u"\u6f22\u5b57.anki", "new.anki"); os.utime("new.anki", (1293402264,1293402264))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 1] Operation not permitted: 'new.anki'

Note that passing numbers into os.utime returns an error.

----------
components: IO
messages: 124684
nosy: Aaron.Masover
priority: normal
severity: normal
status: open
title: os.utime returns an error on NTFS-3G partition
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10776>
_______________________________________

From report at bugs.python.org  Mon Dec 27 00:47:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Dec 2010 23:47:38 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1293407258.57.0.497313652059.issue9709@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thorsten: my recommendation is to ignore this issue in your software. It's just a warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Mon Dec 27 00:54:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Dec 2010 23:54:28 +0000
Subject: [issue10757] zipfile.write, arcname should be bytestring
In-Reply-To: <1293295027.59.0.0932649866073.issue10757@psf.upfronthosting.co.za>
Message-ID: <4D17D5B0.5010707@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So, in reverse of issue 4871, it appears that in this case the API should reject bytes input with an appropriate error message.

-1. It is quite common to produce ill-formed zipfiles, and other
ziptools are interpreting them in violation of the format spec.
Python needs to support creation of such broken zipfiles,
even though it may not be able to read them back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Mon Dec 27 00:59:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 26 Dec 2010 23:59:26 +0000
Subject: [issue10776] os.utime returns an error on NTFS-3G partition
In-Reply-To: <1293405262.1.0.932340163478.issue10776@psf.upfronthosting.co.za>
Message-ID: <1293407966.12.0.773686692138.issue10776@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?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10776>
_______________________________________

From report at bugs.python.org  Mon Dec 27 01:12:09 2010
From: report at bugs.python.org (Peter)
Date: Mon, 27 Dec 2010 00:12:09 +0000
Subject: [issue10777] xml.etree.register_namespace dictionary changed size
	during iteration
In-Reply-To: <1293408729.9.0.0323219588466.issue10777@psf.upfronthosting.co.za>
Message-ID: <1293408729.9.0.0323219588466.issue10777@psf.upfronthosting.co.za>


New submission from Peter <p.j.a.cock at googlemail.com>:

The following was found testing the Biopython unit tests (latest code from git) against Python 3.2 beta 2 (compiled from source on 64 bit Linux Ubuntu). Reduced test case:

$ python3.2
Python 3.2b2 (r32b2:87398, Dec 26 2010, 19:01:30) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree
>>> ElementTree.register_namespace("xs", "http://www.w3.org/2001/XMLSchema")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/peterjc/lib/python3.2/xml/etree/ElementTree.py", line 1071, in register_namespace
    for k, v in _namespace_map.items():
RuntimeError: dictionary changed size during iteration


Suggested fix, replace this:

def register_namespace(prefix, uri):
    if re.match("ns\d+$", prefix):
        raise ValueError("Prefix format reserved for internal use")
    for k, v in _namespace_map.items():
        if k == uri or v == prefix:
            del _namespace_map[k]
    _namespace_map[uri] = prefix


with something like this:

def register_namespace(prefix, uri):
    if re.match("ns\d+$", prefix):
        raise ValueError("Prefix format reserved for internal use")
    for k, v in list(_namespace_map.items()):
        if k == uri or v == prefix:
            del _namespace_map[k]
    _namespace_map[uri] = prefix


Note that cElementTree seems to be OK.

Note that Python 3.1 was not affected as it didn't even have register_namespace,

$ python3
Python 3.1.2 (r312:79147, Sep 27 2010, 09:57:50) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree
>>> ElementTree.register_namespace("xs", "http://www.w3.org/2001/XMLSchema")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'register_namespace'

----------
components: XML
messages: 124688
nosy: maubp
priority: normal
severity: normal
status: open
title: xml.etree.register_namespace dictionary changed size during iteration
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10777>
_______________________________________

From report at bugs.python.org  Mon Dec 27 01:29:52 2010
From: report at bugs.python.org (Aaron Masover)
Date: Mon, 27 Dec 2010 00:29:52 +0000
Subject: [issue10776] os.utime returns an error on NTFS-3G partition
In-Reply-To: <1293405262.1.0.932340163478.issue10776@psf.upfronthosting.co.za>
Message-ID: <1293409792.42.0.530371241479.issue10776@psf.upfronthosting.co.za>


Aaron Masover <amasover at gmail.com> added the comment:

The Anki author suggested that it was a python bug. However, that example command works on a drive set with different permissions, so this looks more like an NTFS-3G bug.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10776>
_______________________________________

From report at bugs.python.org  Mon Dec 27 01:45:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 00:45:10 +0000
Subject: [issue10757] zipfile.write,
	arcname should be allowed to be a byte string
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1293410710.01.0.448580835766.issue10757@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, this is the same treat-strings-and-byte-strings-equivalently-in-the-same-API problem that we've had elsewhere.  It'll require a bit of refactoring to make it work.

On read zipfile decodes filenames using cp437 if the utf-8 flag isn't set.  Logically, then, a binary string should be encoded using cp437.  Since cp437 has a character corresponding to each of the 256 bytes, it seems to me it should be enough to decode a binary filename using cp437 and set a flag that _encodeFilenameFlags would respect and re-encode to cp437 instead of utf-8.  That might produce unexpected results if someone passes in a binary filename encoded in some other character set, but it would be consistent with how zipfiles work and so should be at least as interoperable as zipfiles normally are.

----------
title: zipfile.write, arcname should be bytestring -> zipfile.write, arcname should be allowed to be a byte string

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10757>
_______________________________________

From report at bugs.python.org  Mon Dec 27 02:46:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 27 Dec 2010 01:46:29 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293414389.27.0.701312525481.issue10764@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

PyPy has exactly the same issue. PyPy's workaround is to have a custom version of sysconfig.py, but this is really a hack.
If these config_vars are really determined at compile time, IMO they should be built in the interpreter (in a _sysconfig module?). This would even work on non-posix platforms.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Mon Dec 27 02:51:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 01:51:00 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1293414660.52.0.0629579671719.issue9738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r87504 documents encodings of error functions.
r87505 documents encodings of unicode functions.
r87506 documents encodings of AST, compiler, parser and PyRun functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Mon Dec 27 02:57:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 01:57:03 +0000
Subject: [issue10778] decoding_fgets() (tokenizer.c) decodes the filename from
	the wrong encoding
In-Reply-To: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>
Message-ID: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

decoding_fgets() decodes the input filename from UTF-8 whereas the filename is encoded to the filesystem encoding. PyUnicode_DecodeFSDefault() should be used.

decoding_fgets() raises a SyntaxError("Non-UTF-8 code starting with '\xHH' in file xxx on line xxx, but no encoding declared; ...").

indenterror() (inconsistent use of tabs and spaces in indentation) and

----------
components: Interpreter Core, Unicode
messages: 124693
nosy: haypo
priority: normal
severity: normal
status: open
title: decoding_fgets() (tokenizer.c) decodes the filename from the wrong encoding
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10778>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:05:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:05:48 +0000
Subject: [issue10779] Change filename encoding to FS encoding in
	PyErr_WarnExplicit()
In-Reply-To: <1293415548.91.0.0358465969488.issue10779@psf.upfronthosting.co.za>
Message-ID: <1293415548.91.0.0358465969488.issue10779@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyErr_WarnExplicit() expects a filename encoded to UTF-8. This function is only called twice in the Python interpreter: compiler_assert() (with "assertion is always true, perhaps remove parentheses?") and symtable_warn() (eg. with "name 'xxx' is assigned to before global declaration"), and both functions pass a filename encoded to the filesystem encoding.

PyErr_WarnExplicit() should use the filesystem encoding instead of UTF-8 to decode the filename. I already did the same change in issue #9713 and #10114 (r85569).

Attached patch fixes this issue.

See also issue #10778 (decoding_fgets() (tokenizer.c) decodes the filename from the wrong encoding).

----------
components: Interpreter Core, Unicode
files: warnexplicit_fsencoding.patch
keywords: patch
messages: 124694
nosy: haypo
priority: normal
severity: normal
status: open
title: Change filename encoding to FS encoding in PyErr_WarnExplicit()
versions: Python 3.2
Added file: http://bugs.python.org/file20170/warnexplicit_fsencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10779>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:06:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:06:56 +0000
Subject: [issue10778] decoding_fgets() (tokenizer.c) decodes the filename from
	the wrong encoding
In-Reply-To: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>
Message-ID: <1293415616.06.0.224589453755.issue10778@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #10779 (Change filename encoding to FS encoding in PyErr_WarnExplicit()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10778>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:07:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:07:08 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1293415628.13.0.0740127619912.issue9738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

While documenting encodings, I found two issues: #10778 and #10779.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:30:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:30:43 +0000
Subject: [issue10780] Fix filename encoding in
	PyErr_SetFromWindowsErrWithFilename() (and
	PyErr_SetExcFromWindowsErrWithFilename())
In-Reply-To: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>
Message-ID: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyErr_SetFromWindowsErrWithFilename() expects a filename encoded to UTF-8. It is called by win32_error() function of the nt (posix) module, and win32_error() is called on an error in the bytes implementation of a function (if the argument is a byte string, not an Unicode string). But on Windows, bytes filenames are encoded to the ANSI code page, not to UTF-8.

PyErr_SetExcFromWindowsErrWithFilename() expects also a filename encoded to UTF-8. It is not used in Python core, but I think that it should be fixed too.

See also #10779 (and #9713 and #10114).

----------
components: Interpreter Core, Unicode, Windows
messages: 124697
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix filename encoding in PyErr_SetFromWindowsErrWithFilename() (and PyErr_SetExcFromWindowsErrWithFilename())
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10780>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:36:01 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 27 Dec 2010 02:36:01 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1293417361.45.0.260513769137.issue10576@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

1) what I mean is that if a callback rejects GC, the GC algorithm may find its condition for invoking GC in the first place to be still valid immediately afterwards, so doing a GC will be immediately retried.  I have to check, but it could mean that more changes would be required.
2) Of course callbacks have to know, e.g. those that intend to gather statisctic or measure the time of GC.  They have started a timer on the "start" opcode, and expect a "stop" code to follow.  They have to get some "canceled" code for their bookkeeping to work.

Then additionally we have the question: Should you be able to cancel a direct gc request (like calling gc.collect()) or just the automatic one?

This then starts to be a much more complicated change, perhaps one that requires a PEP so I don't think we should do all of that in one gulp.  Once the callback mechanism is in, there is every oppertunity to extend it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:42:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:42:12 +0000
Subject: [issue10780] Fix filename encoding in
	PyErr_SetFromWindowsErrWithFilename() (and
	PyErr_SetExcFromWindowsErrWithFilename())
In-Reply-To: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>
Message-ID: <1293417732.15.0.359424626496.issue10780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

issue10780.patch fixes this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file20171/issue10780.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10780>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:42:39 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 27 Dec 2010 02:42:39 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1293417759.36.0.171437051543.issue10296@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I _think_ that in our old 2.5 python (which had a backported ctypes from 2.6 to support 64 bits) we always got the JIT debugger i.e. with _ctypes.pyd and _ctypes_d.pyd.

This api, "DebugBreak" always invokes the JIT debugger, however the program was compiled (_NDEBUG, DEBUG, or not).
This is done by raising the breakpoint exception and apparently _ctypes.pyd is catching that exception and handling it, but only in release mode, while I think it shouldn't do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10296>
_______________________________________

From report at bugs.python.org  Mon Dec 27 03:44:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:44:16 +0000
Subject: [issue10780] Fix filename encoding in
	PyErr_SetFromWindowsErrWithFilename() (and
	PyErr_SetExcFromWindowsErrWithFilename())
In-Reply-To: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>
Message-ID: <1293417856.77.0.537891228456.issue10780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

issue10780_mbcs_ignore.patch is a safer but more complex fix: use mbcs decoder with the ignore error handler. Even if issue10780.patch might raise a UnicodeDecodeError, I prefer it because it's shorter, simpler and so easier to maintain the code.

----------
Added file: http://bugs.python.org/file20172/issue10780_mbcs_ignore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10780>
_______________________________________

From report at bugs.python.org  Mon Dec 27 04:02:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 03:02:05 +0000
Subject: [issue5871] email.header.Header too lax with embeded newlines
In-Reply-To: <1240953937.2.0.828159818097.issue5871@psf.upfronthosting.co.za>
Message-ID: <1293418925.57.0.546211336429.issue5871@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've considered this a bit more deeply, and it turns out to be simpler to fix than I originally thought, assuming the fix is acceptable.

When a message is parsed we obviously wind up with headers that don't have any embedding issues.  So, if we check for embedded headers at message production time and reject them, we can't be breaking any round-trip properties of the package.  The only way for a header malformed in this way to get produced is through it being added to a Message object via one of the header adding APIs.  Further, for this specific issue we are only worried about things that look like header labels that follow a newline and don't have whitespace in front of them.  We don't have to worry about the other RFC restrictions on headers in order to fix this.

I tried a patch that checked at header add time, and while that is potentially workable it got fairly complicated and is a bit fragile (did I get *all* the places a header can be added?)  Instead, the attached patch takes the approach of throwing an error for an embedded header at message serialization time.  The advantage here is that all headers are run through Header.encode on serialization, so there's only one bit of code that needs to be modified to pretty much guarantee that header injection can't happen.

There are code paths for producing individual headers that don't go through encode, but these don't produce complete messages, so it shouldn't be a problem (and may even be a feature).

Barry, do you think this is indeed enough of a security issue that this fix (if acceptable) should be backported to 2.6?

I should note that this patch produces a situation unusual[*] for the email package, where serialization may throw an error (but only on a Message object that has been modified).  Also, I'm reusing HeaderParseError, which may not be optimal, although it does seem at least semi-logical.

[*] Generator currently only throws an error itself in one place, if it encounters a bytes payload for a text Message.  Again, something that can only happen in a modified Message, so this seems analogous.

----------
keywords: +patch
stage: unit test needed -> patch review
versions: +Python 2.7, Python 3.1
Added file: http://bugs.python.org/file20173/header_injection.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________

From report at bugs.python.org  Mon Dec 27 04:02:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 03:02:41 +0000
Subject: [issue10778] decoding_fgets() (tokenizer.c) decodes the filename from
	the wrong encoding
In-Reply-To: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>
Message-ID: <1293418961.74.0.0176266346774.issue10778@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, ignore "indenterror() (inconsistent use of tabs and spaces in indentation) and", I forgot to remove it. indenterror() is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10778>
_______________________________________

From report at bugs.python.org  Mon Dec 27 05:42:00 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 27 Dec 2010 04:42:00 +0000
Subject: [issue10573] Consistency in unittest assert methods: order of actual, 
	expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1293424920.48.0.0302577490612.issue10573@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

The issue10573.diff file with the time stamp 20:03 has a lot of document changes that don't have corresponding code changes?

----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Mon Dec 27 08:25:32 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 27 Dec 2010 07:25:32 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1293434732.09.0.0467622627564.issue10576@psf.upfronthosting.co.za>


Lukas Lueg <lukas.lueg at gmail.com> added the comment:

Agreed, let's have the simple callback first.

To solve 2) later on, we could have the callback proposed here be the 'execution'-callback. It neither has nor will have the capability to prevent garbage-collection.
We can introduce another 'prepare'-callback later which is called when the gc-modules decides that it is time for collection. Callbacks may react with a negative value so execution does not happen and the execution-callbacks are also never called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Mon Dec 27 10:32:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Dec 2010 09:32:27 +0000
Subject: [issue10771] descriptor protocol documentation has two different
	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293442347.24.0.101506559147.issue10771@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree that the "owner" terminology imprecise.
Will work on a doc fix when I get chance.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10771>
_______________________________________

From report at bugs.python.org  Mon Dec 27 12:19:38 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Dec 2010 11:19:38 +0000
Subject: [issue10774] test_logging leaves temp files
In-Reply-To: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>
Message-ID: <1293448778.98.0.845451341652.issue10774@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k (r87512).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10774>
_______________________________________

From report at bugs.python.org  Mon Dec 27 15:37:55 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 27 Dec 2010 14:37:55 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1293460675.59.0.710512664265.issue10626@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The reason for the bad interaction is that some of the tests in test_logging disable all existing loggers (due to the configuration tests - disabling of existing loggers is explicitly tested for), but as a side effect this also disabled the concurrent.futures logger.

I've made a change to test_logging which preserves the disabled state of all existing loggers across tests, and now all is well when testing

regrtest.py test_concurrent_futures test_logging test_concurrent_futures

after applying Brian's patch of 24 Dec 2010.

The change has been checked into py3k (r87513). However, this raises the wider issue of other loggers in stdlib and the effect on them of logging configuration calls. I'll raise this on python-dev for discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Mon Dec 27 16:36:13 2010
From: report at bugs.python.org (Goffi)
Date: Mon, 27 Dec 2010 15:36:13 +0000
Subject: [issue10781] minidom Node.writexml method doesn't manage encoding
	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>


New submission from Goffi <goffi at goffi.org>:

G'day,

While translating my software to french, I realised that minidom's writexml method doesn't handle "encoding" parameter correctly: it changes the header of the resulting xml, but not the encoding itself (which it should according to the documentation: http://docs.python.org/library/xml.dom.minidom.html).

The given example doesn't work with writexml; but if I save by myself using the toxml's encoding parameter (like in the commented line), it works as expected.

Anyway, it would be better if minidom could handle unicode string directly.

----------
components: XML
files: test_minidom.py
messages: 124709
nosy: Goffi
priority: normal
severity: normal
status: open
title: minidom Node.writexml method doesn't manage encoding parameter correctly
versions: Python 2.6
Added file: http://bugs.python.org/file20174/test_minidom.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10781>
_______________________________________

From report at bugs.python.org  Mon Dec 27 17:02:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Dec 2010 16:02:33 +0000
Subject: [issue10781] minidom Node.writexml method doesn't manage encoding
	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293465753.6.0.0110812917227.issue10781@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The documentation is incorrect; writexml does not support an encoding parameter. Only Document nodes support the encoding parameter in writexml, and it is intentional that its only effect is to fill out the XML declaration.

I don't understand the last sentence in your report: what is it that you want to see supported, and how is that related to this issue?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10781>
_______________________________________

From report at bugs.python.org  Mon Dec 27 17:07:10 2010
From: report at bugs.python.org (Goffi)
Date: Mon, 27 Dec 2010 16:07:10 +0000
Subject: [issue10781] minidom Node.writexml method doesn't manage encoding
	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293466030.22.0.60137538393.issue10781@psf.upfronthosting.co.za>


Goffi <goffi at goffi.org> added the comment:

Thanks for your quick reply

The last sentence has nothing to do with the report, it was just a general remark that it would be nice if minidom could support unicode string directly.

Should I send a mail to docs at python.org to report the doc issue, or this one is sufficient ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10781>
_______________________________________

From report at bugs.python.org  Mon Dec 27 17:51:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 16:51:46 +0000
Subject: [issue8889] test_support.transient_internet fails on Freebsd because
	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1293468706.3.0.745406758528.issue8889@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I never forward ported this, but it was fixed in a different way in python3 during a complete rewrite of transient_internet for other reasons.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8889>
_______________________________________

From report at bugs.python.org  Mon Dec 27 17:54:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 16:54:11 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1293468851.33.0.188214691044.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Too late for 3.2, will implement for 3.3.

----------
title: The email package should defer to the codecs module for	all aliases -> The email package should defer to the codecs module for all aliases
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:05:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 17:05:00 +0000
Subject: [issue1685453] email package should work better with unicode
Message-ID: <1293469500.4.0.874141286837.issue1685453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Now that we are primarily focused on Python3 development, collecting "unicode" issues is not really all that useful (at least not to me, and I'm currently doing the email maintenance), so I'm closing this.  All the relevant issues are assigned to me anyway, so I'll be dealing with them by and by.

----------
dependencies:  -Add decode_header_as_string method to email.utils, Add utf8 alias for email charsets, Unicode email address helper, email package and Unicode strings handling, email.Header (via add_header) encodes non-ASCII content incorrectly, email.Header encode() unicode P2.6, email.header unicode fix, email.parser: impossible to read messages encoded in a different encoding, email/base64mime.py cannot work, email/charset.py convert() patch, smtplib is broken in Python3, unicode in email.MIMEText and email/Charset.py
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1685453>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:05:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Dec 2010 17:05:55 +0000
Subject: [issue10781] minidom Node.writexml method doesn't manage encoding
	parameter correctly
In-Reply-To: <1293466030.22.0.60137538393.issue10781@psf.upfronthosting.co.za>
Message-ID: <4D18C76F.9020103@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The last sentence has nothing to do with the report, it was just a general remark that 
> it would be nice if minidom could support unicode string directly.

minidom most certainly supports Unicode directly. All element names,
attribute names, and text nodes carry Unicode objects.

> Should I send a mail to docs at python.org to report the doc issue, 
> or this one is sufficient ?

This one is sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10781>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:17:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 17:17:29 +0000
Subject: [issue1243730] Big speedup in email message parsing
Message-ID: <1293470249.15.0.555102313872.issue1243730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since this is a performance hack and is considerably invasive of the feedparser code (and needs updating), I'm deferring it to 3.3.

----------
stage: unit test needed -> patch review
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1243730>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:28:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 17:28:55 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1293470935.15.0.44858696415.issue3244@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:33:11 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 27 Dec 2010 17:33:11 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293471191.44.0.99391917587.issue10764@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/issue10764>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:38:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 17:38:44 +0000
Subject: [issue1162477] Parsing failures in parsedate_tz
Message-ID: <1293471524.29.0.301923442551.issue1162477@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Somehow I missed this in my pre-beta feature request review :(

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1162477>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:42:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 17:42:10 +0000
Subject: [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1293471730.9.0.927126111137.issue9864@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:43:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 17:43:07 +0000
Subject: [issue1043706] External storage protocol for large email messages
Message-ID: <1293471787.5.0.343402959667.issue1043706@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1043706>
_______________________________________

From report at bugs.python.org  Mon Dec 27 18:43:36 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 27 Dec 2010 17:43:36 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293471816.32.0.200430595388.issue10764@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Yes that's what we said we would do, and was the second step after the extraction of sysconfig from distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:02:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:02:30 +0000
Subject: [issue6533] Make test_xmlrpc_net functional in the absence of
	time.xmlrpc.com
In-Reply-To: <1248192079.14.0.84793941186.issue6533@psf.upfronthosting.co.za>
Message-ID: <1293472950.28.0.58256882779.issue6533@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The skip was added and the service is back and has been for a while, so I'm closing this, but see also issue 6027.

----------
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6533>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:05:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 27 Dec 2010 18:05:17 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1293473117.4.0.769274607157.issue10753@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I agree that semi-colon separated segments (params) can be in PATH portion of the url. I was trying to find out, how a path;params would be useful in wsgiref request_uri's PATH_INFO variable , wherein I assumed PATH_INFO should be a file-system path or a method name.

After doing a bit of study, I find that ';' can be part of PATH_INFO in wsgiref compliant servers. I find a couple of bugs related to issues where ';' in PATH_INFO is not handled properly in other systems - http://bit.ly/g4UHhX

So, I think, we can have ';' as safe character so that it is prevented from quoting.

Also, RFC 3986 in Section 3.3 says that ';' '=' and ',' can be considered safe in the PATH component. Should we include those too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:09:36 2010
From: report at bugs.python.org (Ben Gamari)
Date: Mon, 27 Dec 2010 18:09:36 +0000
Subject: [issue10782] Not possible to cross-compile due to poor detection of
	%lld support in printf
In-Reply-To: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>
Message-ID: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>


New submission from Ben Gamari <bgamari at gmail.com>:

Configure.in assumes that %lld is not supported by printf if cross-compiling. This causes build errors in pyport.h,

In file included from Include/Python.h:58:0,
                 from Parser/parser.c:8:
Include/pyport.h:243:13: error: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"
...

What is one supposed to do about this short of changing the configure script to assume support by default.

----------
components: Build
messages: 124722
nosy: bgamari
priority: normal
severity: normal
status: open
title: Not possible to cross-compile due to poor detection of %lld support in printf
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10782>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:20:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:20:18 +0000
Subject: [issue740495] API enhancement: poplib.MailReader()
Message-ID: <1293474018.45.0.443702413844.issue740495@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue740495>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:20:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:20:54 +0000
Subject: [issue634412] RFC 2112 in email package
Message-ID: <1293474054.18.0.484340251978.issue634412@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue634412>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:24:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:24:09 +0000
Subject: [issue795081] email.Message param parsing problem II
Message-ID: <1293474249.61.0.874780741457.issue795081@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue795081>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:26:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:26:58 +0000
Subject: [issue1025395] email.Utils.parseaddr fails to parse valid addresses
Message-ID: <1293474418.68.0.975338321518.issue1025395@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1025395>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:27:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:27:41 +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: <1293474461.8.0.981480483523.issue8769@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:28:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:28:16 +0000
Subject: [issue9967] encoded_word regular expression in
	email.header.decode_header()
In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>
Message-ID: <1293474496.62.0.592278861704.issue9967@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9967>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:30:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:30:50 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1293474650.7.0.644279740368.issue9298@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Mon Dec 27 19:35:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 18:35:31 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1293474931.28.0.928610110649.issue10753@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If the RFC says they are safe it seems like we should include them in the safe list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Mon Dec 27 20:18:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 19:18:56 +0000
Subject: [issue1379416] email.Header encode() unicode P2.6
Message-ID: <1293477536.09.0.0459472153465.issue1379416@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to 2.7 in r87515.  On second thought there's no reason to forward port the test because Python3 doesn't have the equivalent type-promotion issues.

----------
nosy:  -BreamoreBoy
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/issue1379416>
_______________________________________

From report at bugs.python.org  Mon Dec 27 20:27:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 19:27:47 +0000
Subject: [issue8719] buildbot: segfault on FreeBSD (signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1293478067.67.0.899165236394.issue8719@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

https://github.com/haypo/faulthandler/wiki can be tried on this buildbot to get more information about this issue. But the module have to be installed on this host.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8719>
_______________________________________

From report at bugs.python.org  Mon Dec 27 20:29:46 2010
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Dec 2010 19:29:46 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293478186.71.0.223256446102.issue6210@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +stoneleaf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Mon Dec 27 20:59:46 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Dec 2010 19:59:46 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1293479986.26.0.682359680328.issue9893@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

But if you have a local copy of the Vim files from the community what is preventing you from editing them for new keywords and sending a patch to the maintainer so that the rest of the community is brought up to speed that much faster?

I suspect that not many people beyond core devs use the Misc/Vim file while more people in the community use the vim.org files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:09:56 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 27 Dec 2010 20:09:56 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

Is the struct.pack() function supposed to automatically encode Unicode strings into binary?  For example:

>>> struct.pack("10s","Jalape\u00f1o")
b'Jalape\xc3\xb1o\x00'
>>>

This is Python 3.2b1.

----------
components: Library (Lib)
messages: 124727
nosy: dabeaz
priority: normal
severity: normal
status: open
title: struct.pack() and Unicode strings
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:10:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 20:10:55 +0000
Subject: [issue10779] Change filename encoding to FS encoding in
	PyErr_WarnExplicit()
In-Reply-To: <1293415548.91.0.0358465969488.issue10779@psf.upfronthosting.co.za>
Message-ID: <1293480655.5.0.401109757707.issue10779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r87517.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10779>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:11:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 20:11:34 +0000
Subject: [issue7056] regrtest runtest_inner calls findtestdir unnecessarily
In-Reply-To: <1254685310.19.0.164822003436.issue7056@psf.upfronthosting.co.za>
Message-ID: <1293480694.47.0.640645796048.issue7056@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed (redid, actually) 2nd patch in r87516.  I may or may not backport it.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7056>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:11:41 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 27 Dec 2010 20:11:41 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293480701.48.0.913199979362.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Note: This is what happens in Python 2.6.4:

>>> import struct
>>> struct.pack("10s",u"Jalape\u00f1o")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: argument for 's' must be a string
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:12:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 20:12:35 +0000
Subject: [issue10778] decoding_fgets() (tokenizer.c) decodes the filename from
	the wrong encoding
In-Reply-To: <1293415023.66.0.544290735249.issue10778@psf.upfronthosting.co.za>
Message-ID: <1293480755.03.0.190542611696.issue10778@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r87518.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10778>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:17:00 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 27 Dec 2010 20:17:00 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293481020.75.0.364682105729.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Hmmm. Well, the docs seem to say that it's allowed and that it will be encoded as UTF-8.  

Given the treatment of Unicode/bytes elsewhere in Python 3, all I can say is that this behavior is rather surprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:19:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 20:19:03 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293481143.5.0.80478093492.issue10783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But clearly intentional, and now enshrined in released code.

----------
nosy: +mark.dickinson, r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Mon Dec 27 21:28:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 27 Dec 2010 20:28:24 +0000
Subject: [issue4212] email.LazyImporter does not use absolute imports
In-Reply-To: <1225087041.33.0.0357186656553.issue4212@psf.upfronthosting.co.za>
Message-ID: <1293481704.05.0.321922686781.issue4212@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

LazyImporter isn't used in Python3.  Without someone motivated to propose a patch this isn't going to be changed, so I'm closing the issue.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4212>
_______________________________________

From report at bugs.python.org  Mon Dec 27 22:37:37 2010
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Dec 2010 21:37:37 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293485857.86.0.678566183543.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I like MRAB's suggestion best:

MRAB wrote:
> Suggestion: an explicit 'raise' in the exception handler excludes the
> context, but if you want to include it then 'raise with'. For example:
>
> # Exclude the context
> try:
>     command_dict[command]()
> except KeyError:
>     raise CommandError("Unknown command")
>
> # Include the context
> try:
>     command_dict[command]()
> except KeyError:
>     raise with CommandError("Unknown command")

I think we can even strike off the verbiage "in the exception handler"... that way, raise always does the same thing -- raise KeyError will raise a KeyError, always, not sometimes a KeyError and sometimes a KeyError nested in a WhatEverError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Mon Dec 27 22:52:37 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 27 Dec 2010 21:52:37 +0000
Subject: [issue10782] Not possible to cross-compile due to poor detection of
	%lld support in printf
In-Reply-To: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>
Message-ID: <1293486757.55.0.687408005324.issue10782@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Use config.cache to set ac_cv_have_long_long_format

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10782>
_______________________________________

From report at bugs.python.org  Mon Dec 27 23:15:46 2010
From: report at bugs.python.org (David Bolen)
Date: Mon, 27 Dec 2010 22:15:46 +0000
Subject: [issue8719] buildbot: segfault on FreeBSD (signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1293488146.48.0.278629930558.issue8719@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Wouldn't that module have to be put into the actual source tree, since the tests run beneath the interpreter/libraries that are built for the test?

That may be what you meant, but "installed on this host" made me think I could do something external on the buildbot which I don't think would work given that the module has to be called from within the tests themselves?

-- David

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8719>
_______________________________________

From report at bugs.python.org  Mon Dec 27 23:53:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Dec 2010 22:53:54 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293490434.93.0.594281730521.issue6210@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree with the OP that we need a way to either suppress chaining or have it turned-off by default.  A person writing an exception handler should have control over what the user sees.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Mon Dec 27 23:55:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Dec 2010 22:55:56 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293490556.72.0.718942634363.issue10783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Can we at least offer an optional choice of encoding?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 00:08:23 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 27 Dec 2010 23:08:23 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293491303.51.0.546327659377.issue6210@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 00:21:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Dec 2010 23:21:14 +0000
Subject: [issue8719] buildbot: segfault on FreeBSD (signal 11)
In-Reply-To: <1273875581.36.0.231394687131.issue8719@psf.upfronthosting.co.za>
Message-ID: <1293492074.0.0.597533800171.issue8719@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/issue8719>
_______________________________________

From report at bugs.python.org  Tue Dec 28 00:32:01 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 27 Dec 2010 23:32:01 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293492721.22.0.890776439576.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Why is it even encoding at all?  Almost every other part of Python 3 forces you to be explicit about bytes/string conversion.  For example:

struct.pack("10s", x.encode('utf-8'))

Given that automatic conversion is documented, it's not clear what can be done at this point.  However, there are very few other parts of Python 3 that perform implicit string-byte conversions like this (at least that I know of off-hand).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 01:03:38 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Dec 2010 00:03:38 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293494618.57.0.152268951753.issue10783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Many of these kind of "decisions" were made quickly, haphazardly, and with almost no discussion and were made by contributors who were new to Python core development (no familiar with the API norms).

Given the rats nest of bytes/text problems in Py3.0 and Py3.1, I think it is fair game to fix it now.  The APIs have not been shaken-out and battle-tested through wide-spread adoption, so it was fair to expect that the first experienced user to come along would find these rough patches.  

ISTM, this should get fixed.  The most innocuous way to do it is to add a warning for the implicit conversion.  That way, any existing 3.x code (probably precious little) would continue to run.  Another option is to just finish the job by adding an encoding parameter that defaults to utf-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 01:14:03 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Dec 2010 00:14:03 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293495243.64.0.30838622421.issue10783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

A possible answer to "why is this encoding at all" was probably to make it easier to transition code from python 2.x where strings were usually ascii and it would make no difference in output if encoded in utf-8.  The 2-to-3 fixer was good at handling name changes but not bytes/text issues.  That is just a guess at what the developer may have been thinking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 01:21:11 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 28 Dec 2010 00:21:11 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293495671.9.0.54616848367.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I encountered this issue is in the context of distributed computing/interprocess communication involving binary-encoded records (and encoding/decoding such records using struct). At its core, this is all about I/O--something where encodings and decoding matter a lot.  Frankly, it was quite surprising that a unicode string would silently pass through struct and turn into bytes.  IMHO, the fact that this is even possible encourages a sloppy usage of struct that favors programming convenience over correctness--something that's only going to end badly for the poor soul who passes non-ASCII characters into struct without knowing it. 

A default encoding might be okay as long as it was set to something like ASCII or Latin-1 (not UTF-8).  At least then you'd get an encoding error for characters that don't fit into a byte.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 01:29:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 00:29:56 +0000
Subject: [issue10780] Fix filename encoding in
	PyErr_SetFromWindowsErrWithFilename() (and
	PyErr_SetExcFromWindowsErrWithFilename())
In-Reply-To: <1293417043.69.0.869420684931.issue10780@psf.upfronthosting.co.za>
Message-ID: <1293496196.26.0.447307651354.issue10780@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r87519.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10780>
_______________________________________

From report at bugs.python.org  Tue Dec 28 01:47:24 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 28 Dec 2010 00:47:24 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293497244.28.0.721033161003.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Actually, here's another one of my favorite examples:

>>> import struct
>>> struct.pack("s","\xf1")
b'\xc3'
>>> 

Not only does this not encode the correct value, it doesn't even encode the entire UTF-8 encoding (just the first byte of it).   Like I said, pity the poor bastard who puts something that in their code and they spend the whole day trying figure out where in the hell '\xf1' magically got turned into '\xc3'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 01:56:32 2010
From: report at bugs.python.org (Jacques Grove)
Date: Tue, 28 Dec 2010 00:56:32 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293497792.31.0.525971195017.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Testing issue2636-20101224.zip:

Nested modifiers seems to hang the regex compilation when used in a non-capturing group e.g.:

re.compile("(?:(?i)foo)")

or

re.compile("(?:(?u)foo)")


No problem on stock Python 2.6.5 regex engine.

The unnested version of the same regex compiles fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:07:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 01:07:47 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293490434.93.0.594281730521.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293498463.4190.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A person writing an exception handler should have control over what
> the user sees.

There is already support for this in the traceback module (see the
"chain" parameter to various funcs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:13:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 01:13:39 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293498819.06.0.567356166964.issue10783@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This "feature" was introduced in a big commit from Guido van Rossum (made before Python 3.0): r55500. The changelog is strange because it starts with "Make test_zipfile pass. The zipfile module now does all I/O in binary mode using bytes." but ends with "The _struct needed a patch to support bytes, str8 and str for the 's' and 'p' formats.". Why was _struct patched at the same time?

Implicit conversion bytes and str is a very bad idea, it is the root of all confusion related to Unicode. The experience with Python 2 demonstrated that it should be changed, and it was changed in Python 3.0. But "Python 3.0" is a big project, it has many modules. Some modules were completly broken in Python 3.0, it works better with 3.1, and we hope that it will be even better with 3.2.

Attached patch removes the implicit conversion for 'c', 's' and 'p' formats. I did a similar change in ctypes, 5 months ago: issue #8966.

If a program written for Python 3.1 fails because of the patch, it can use explicit conversion to stay compatible with 3.1 and 3.2 (patched). I think that it's better to use explicit conversion.

Implicit conversion on 'c' format is really weird and it was not documented correctly: the note (1) is attached to "b" format, not to the "c" format. Example:

   >>> struct.pack('c', '?')
   struct.error: char format requires bytes or string of length 1
   >>> len('?')
   1

There is also a length issue with the s format: struct.pack() truncates unicode string to a length in bytes, not in character, it is confusiong.

  >>> struct.pack('2s', 'ha')
   b'ha'
   >>> struct.pack('2s', 'h?')
   b'h\xc3'
   >>> struct.pack('3s', 'h?')
   b'h\xc3\xa9'

Finally, I don't like implicit conversion from unicode to bytes on pack, because it's not symmetrical.

   >>> struct.pack('3s', 'h?')
   b'h\xc3\xa9'
   >>> struct.unpack('3s', b'h\xc3\xa9')
   (b'h\xc3\xa9',)

(str -> pack() -> unpack() -> bytes)

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file20175/struct.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:14:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 01:14:44 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293498884.83.0.160663542058.issue10783@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:24:19 2010
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Dec 2010 01:24:19 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293499459.93.0.310678359199.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> There is already support for this in the traceback module (see the
> "chain" parameter to various funcs).

I'm not sure how that's going to help as I don't want my library code to be responsible for printing out exceptions, I just want them to print reasonably -- and it seems very unreasonable to have the exception I'm converting /from/ show up in the traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:45:53 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 28 Dec 2010 01:45:53 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293500753.55.0.0661874615756.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101228.zip is a new version of the regex module.

Sorry for the delay, the fix took me a bit longer than I expected. :-)

----------
Added file: http://bugs.python.org/file20176/issue2636-20101228.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:46:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 28 Dec 2010 01:46:50 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

After having implemented a similar thing in psutil ( http://code.google.com/p/psutil/issues/detail?id=142 ) I decided to contribute a patch for Python which exposes getpriority() and setpriority() POSIX calls in the os module.

They can be used to get/set process niceness/priority in a fashion similar to os.nice() but extended to *all* processes instead of just os.getpid():
http://linux.die.net/man/2/setpriority

----------
assignee: giampaolo.rodola
keywords: patch
messages: 124751
nosy: giampaolo.rodola, loewis, pitrou
priority: normal
severity: normal
status: open
title: os.getpriority() and os.setpriority()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:47:09 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 28 Dec 2010 01:47:09 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1293500829.98.0.9047297997.issue10784@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Forgot to attach the patch.

----------
Added file: http://bugs.python.org/file20177/getsetpriority.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:47:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 28 Dec 2010 01:47:43 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293500863.65.0.895011169363.issue9333@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's a patch. I think this works more like what you guys are looking for. Tests pass on Windows 7 and I checked it on a Mac to be sure, and it's good there too.

----------
Added file: http://bugs.python.org/file20178/issue9333_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Tue Dec 28 02:51:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 28 Dec 2010 01:51:58 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293501118.68.0.766660735582.issue9333@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

(hit enter too soon, sorry)

The patch makes os.symlink always available on Windows machines, but it will only have an effect when privileged. Windows XP and Windows 2003 will still receive NotImplementedError, as the underlying calls aren't available there. On Vista and 7 for non-privileged users, OSError will be raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Tue Dec 28 03:04:50 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 28 Dec 2010 02:04:50 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1293501890.23.0.378721552296.issue10784@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Tue Dec 28 03:40:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 02:40:23 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The Python parser stores the filename as a byte string. But it decodes the filename on error because most Python functions now use unicode strings. Instead of decoding the filename at error, which may raise a new error, I propose to decode the filename on the creation of the parser object and only store the filename as unicode.

This issue would prepare the last part of the full unicode support (#3080).

----------
components: Interpreter Core, Unicode
files: parse_filename_obj.patch
keywords: patch
messages: 124755
nosy: haypo
priority: normal
severity: normal
status: open
title: parser: store the filename as an unicode object
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20179/parse_filename_obj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Tue Dec 28 03:49:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 02:49:34 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293504574.44.0.196703167198.issue10785@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20179/parse_filename_obj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Tue Dec 28 03:50:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 02:50:16 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293504616.7.0.645918293936.issue10785@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file20180/parser_filename_obj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Tue Dec 28 03:51:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 02:51:45 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1293504705.93.0.55922295823.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #10785 prepares the work for this issue: store input filename as a unicode string, instead of a byte string, in the parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Tue Dec 28 03:51:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 02:51:56 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1293504716.87.0.325746763715.issue3080@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Tue Dec 28 04:31:28 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 28 Dec 2010 03:31:28 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293507088.37.0.677522632654.issue6210@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Regarding syntax, I'm undecided between:

    raise with new_exception

and:

    raise new_exception with caught_exception

I think that the second form is clearer:

    try:
        ...
    exception SomeException as ex:
        raise SomeOtherException() with ex

(I'd prefer 'with' to Steven's 'from') but the first form doesn't force you to provide a name:

    try:
        ...
    exception SomeException:
        raise with SomeOtherException()

and the syntax also means that you can't chain another exception like this:

    try:
        ...
    exception SomeException as ex:
        raise SomeOtherException() with YetAnotherException()

although perhaps Python should just rely on the programmer's good judgement. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 04:47:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 03:47:42 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293508062.7.0.640814669638.issue10783@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

>>> struct.pack('2s', 'ha')
   b'ha'
   >>> struct.pack('2s', 'h?')
   b'h\xc3'
   >>> struct.pack('3s', 'h?')
   b'h\xc3\xa9'

That looks like a *buggy* api to me, too.  I don't see how we can let that stand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 05:01:04 2010
From: report at bugs.python.org (Jacques Grove)
Date: Tue, 28 Dec 2010 04:01:04 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293508864.5.0.369786178549.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Another re.compile performance issue (I've seen a couple of others, but I'm still trying to simplify the test-cases):

re.compile("(?ui)(a\s?b\s?c\s?d\s?e\s?f\s?g\s?h\s?i\s?j\s?k\s?l\s?m\s?n\s?o\s?p\s?q\s?r\s?s\s?t\s?u\s?v\s?w\s?y\s?z\s?a\s?b\s?c\s?d)")

completes in around 0.01s on my machine using Python 2.6.5 standard regex library, but takes around 12 seconds using issue2636-20101228.zip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec 28 05:24:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 04:24:39 +0000
Subject: [issue8009] email.parser.Parser is inefficient with large strings
In-Reply-To: <1267004644.66.0.205268505464.issue8009@psf.upfronthosting.co.za>
Message-ID: <1293510279.44.0.0728742025391.issue8009@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Parser is a legacy API, and message_from_string (which uses it) is just a convenience function.  If performance is an issue for your application, call feedparser directly and optimize the feeding to suit your application.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8009>
_______________________________________

From report at bugs.python.org  Tue Dec 28 05:56:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 04:56:23 +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: <1293512183.72.0.0494000953458.issue1823@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As far as I can tell it is simply wrong per-RFC to put a charset parameter on a mulitpart content-type.  So I think this should, indeed, raise an error on the Multipart subtype.

If someone sets any charset, the CTE is set wrong.  So code that sets charset is already broken, even though tolerant mailers will accept the resulting message (but some mailers won't, as described in this issue).

So, I think set_charset on MIMEMultipart should be deprecated and turned into a no-op in 3.2.

----------
keywords: +easy
nosy: +georg.brandl
stage:  -> needs patch
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1823>
_______________________________________

From report at bugs.python.org  Tue Dec 28 06:01:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 05:01:56 +0000
Subject: [issue5423] Exception raised when attempting to call set_charset on
	an email.mime.multipart once sub-parts have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1293512516.15.0.530378638377.issue5423@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since set_charset should not be valid on a multipart, I don't see a reason to have a separate issue for the post-attach case.

Also, although I haven't searched the RFCs, I don't think we can assume that set_chaset is valid only on text parts, so I don't think the patch will work as a solution.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5423>
_______________________________________

From report at bugs.python.org  Tue Dec 28 06:36:35 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 28 Dec 2010 05:36:35 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1293514595.18.0.0203180513909.issue10784@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Patch looks good, just one thing:

In setpriority(), it should be possible to use the Py_RETURN_NONE; macro instead of INCREFing manually.

----------
components: +Extension Modules
nosy: +rosslagerwall
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Tue Dec 28 07:57:59 2010
From: report at bugs.python.org (cooyeah)
Date: Tue, 28 Dec 2010 06:57:59 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>


New submission from cooyeah <cooyeah at gmail.com>:

The constructor of TextTestRunner class looks like:
def __init__(self, stream=sys.stderr, descriptions=1, verbosity=1)

Since the default parameter is evaluated only once, if sys.stderr is redirected later, the test would still use the old stderr when it was first initialized.

----------
components: Tests
messages: 124764
nosy: cooyeah
priority: normal
severity: normal
status: open
title: unittest.TextTextRunner does not respect redirected stderr
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Tue Dec 28 08:41:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Dec 2010 07:41:51 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293522111.36.0.12330270928.issue10783@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

At this point a feature change seems unlikely, but it's not too late to emit a DeprecationWarning.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 08:53:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Dec 2010 07:53:12 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293522792.04.0.744697879165.issue9333@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good, I only have stylistic remarks:
- We normally don't use windows-specific types in CPython code. Please use int instead of BOOL. And C variables are usually lowercase, even module globals. I suggest something like "static int win32_can_symlink;"
- the enable_symlink() function should be "static" as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Tue Dec 28 08:56:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Dec 2010 07:56:19 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293522979.16.0.0196056761931.issue10783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Errors should not pass silently :-)

Given the buggy behavior, we have several options including just removing the implicit conversion and going back to bytes only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 09:00:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Dec 2010 08:00:14 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293523214.73.0.803237939396.issue10783@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>> At this point a feature change seems unlikely,

Amaury, it is not too late to fix anything that's broken.  New features are out, but we are free to fix anything hosed this badly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 09:24:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Dec 2010 08:24:08 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293524648.01.0.853355278557.issue10783@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But there are probably working usages with unicode strings out there. For example, I've seen code like struct.pack('<6sHHBBB', 'GIF87a', ...)
Do you suggest to make this 3.1 code stop working in 3.2?

In any case, the 'c' format should probably be changed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:07:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 09:07:13 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293522111.36.0.12330270928.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293527280.24502.3.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Amaury> At this point a feature change seems unlikely,
Amaury> but it's not too late to emit a DeprecationWarning.

I prefer to break the API today than having to maintain a broken API for
10 or 20 years :-)  And we have a very small user base using Python 3,
it's easier to change it now, than in the next release.

Amaury> But there are probably working usages with unicode strings out
Amaury> there. For example, I've seen code like
Amaury> struct.pack('<6sHHBBB','GIF87a', ...)
Amaury> Do you suggest to make this 3.1 code stop working in 3.2?

Yes. As I wrote in my previous message, this can be changed to
struct.pack('<6sHHBBB', b'GIF87a', ...), which works on 3.1 and 3.2
(patched).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:30:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:30:51 +0000
Subject: [issue10773] "Building C and C++ Extensions on Windows" documentation
	shows 2.x way of initializing module
In-Reply-To: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>
Message-ID: <1293528651.8.0.727119724523.issue10773@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r87524.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10773>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:35:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:35:41 +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: <1293528941.17.0.720274735512.issue1823@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fine with me to fix this API during beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1823>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:36:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:36:38 +0000
Subject: [issue10738] webbrowser.py bug with Opera on Linux
In-Reply-To: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>
Message-ID: <1293528998.5.0.748383290712.issue10738@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

By all means.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10738>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:38:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:38:40 +0000
Subject: [issue10766] optparse uses %s in gettext calls
In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>
Message-ID: <1293529120.25.0.556728332131.issue10766@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, argparse is new, so that is a different story.  Not so sure about optparse, so I would not put this into 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10766>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:45:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:45:09 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1293529509.04.0.0327145689325.issue9824@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Tue Dec 28 10:51:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:51:52 +0000
Subject: [issue10679] "make altinstall" may clobber OS provided scripts
In-Reply-To: <1292068058.14.0.437553444007.issue10679@psf.upfronthosting.co.za>
Message-ID: <1293529912.5.0.367638817387.issue10679@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r87525.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10679>
_______________________________________

From report at bugs.python.org  Tue Dec 28 11:10:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:10:57 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1293531057.58.0.977013577013.issue2775@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Alas, too late for 3.2 now.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Tue Dec 28 11:18:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:18:28 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1293531508.74.0.216902148156.issue10784@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good.  Would there be a point in making any of the parameters optional?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Tue Dec 28 11:25:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:25:48 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293531948.12.0.0490985563296.issue10783@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree this automatic conversion is broken and should be fixed.  Not sure if emitting a DeprecationWarning now and fixing it 18 months later is the right thing, especially since DeprecationWarnings are now silent.
As Victor says, the incompatibility is explicit, and the fix is simple and fully backwards compatible, while the current behavior will cause nasty intermittent surprises.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 11:32:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 28 Dec 2010 10:32:05 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293531508.74.0.216902148156.issue10784@psf.upfronthosting.co.za>
Message-ID: <4D19BCA2.6060509@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Looks good.  Would there be a point in making any of the parameters optional?

No. The API should look exactly as it does on the system level. Anybody
calling these functions should know how call them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Tue Dec 28 11:38:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:38:46 +0000
Subject: [issue10777] xml.etree.register_namespace dictionary changed size
	during iteration
In-Reply-To: <1293408729.9.0.0323219588466.issue10777@psf.upfronthosting.co.za>
Message-ID: <1293532726.86.0.314212223199.issue10777@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, this should be fixed in r87526.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10777>
_______________________________________

From report at bugs.python.org  Tue Dec 28 11:57:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:57:11 +0000
Subject: [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293533831.89.0.389557108078.issue10768@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87527.  Terry, the reason why calling example() interactively failed is the strange way __doc__ is imported -- it is None in your case and that causes the Tkinter type error.  I fixed this as well.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10768>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:06:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:06:16 +0000
Subject: [issue10767] Lib/test/crashers/README is out of date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293534376.17.0.744265116154.issue10767@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87530.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10767>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:08:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:08:43 +0000
Subject: [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1293534523.6.0.580176391739.issue10742@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r87531.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10742>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:16:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:16:23 +0000
Subject: [issue10781] minidom Node.writexml method doesn't manage encoding
	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293534983.55.0.523210878692.issue10781@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87532.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10781>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:38:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:38:41 +0000
Subject: [issue10708] Misc/porting should be folded in to the development FAQ
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1293536321.12.0.165768787156.issue10708@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same for Misc/SpecialBuilds.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10708>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:39:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:39:24 +0000
Subject: [issue6785] IncompleteRead / BadStatus when parsing
	http://peakoil.mobi
In-Reply-To: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
Message-ID: <1293536364.36.0.596734574782.issue6785@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6785>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:50:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:50:05 +0000
Subject: [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1293537005.15.0.519625119303.issue10739@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree that this belongs in the makefile docs.  Fixed in r87535.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10739>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:51:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:51:11 +0000
Subject: [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1293537071.12.0.440859714693.issue10670@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
Removed message: http://bugs.python.org/msg123928

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10670>
_______________________________________

From report at bugs.python.org  Tue Dec 28 12:53:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:53:35 +0000
Subject: [issue10609] dbm documentation example doesn't work (iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1293537215.47.0.0699153835217.issue10609@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87536.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10609>
_______________________________________

From report at bugs.python.org  Tue Dec 28 13:09:59 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Dec 2010 12:09:59 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293538199.89.0.785194734664.issue10783@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Since the Release Manager agrees with the change, I withdraw my objection.

I have three remarks to the patch: 

- Some examples in the documentation should be fixed:
http://docs.python.org/dev/py3k/library/struct.html#examples
>>> pack('ci', '*', 0x12131415)
will now raise an exception.

- the message "argument for 's' must be a bytes" looks a bit weird. "a bytes object" seems better.

- the 'p' format (Pascal String) should be changed as well. This is the last call to _PyUnicode_AsDefaultEncodedString() in this file...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 13:10:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 12:10:34 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293499459.93.0.310678359199.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293538229.3700.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm not sure how that's going to help as I don't want my library code
> to be responsible for printing out exceptions, I just want them to
> print reasonably -- and it seems very unreasonable to have the
> exception I'm converting /from/ show up in the traceback.

I don't know if it's unreasonable. In some cases it can definitely help.
Besides, if you are writing library code (as opposed to application
code), you shouldn't care at all how tracebacks are displayed, should
you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 14:16:07 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 28 Dec 2010 13:16:07 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293542167.0.0.293693539449.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

As a user of Python 3, I would like echo Victor's comment about fixing the API right now as opposed to having to deal with it later.  I can only speak for myself, but I would guess that anyone using Python 3 already understands that it's bleeding edge and that the bytes/strings distinction is really important.  If fixing this breaks some third party libraries, I say good--they shouldn't have been blindly passing Unicode into struct in the first place.  Better to deal with it now when the number of users is relatively small.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 14:27:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 13:27:49 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293542869.82.0.495074761282.issue10783@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r87537. Thanks Amaury for your review!

I also removed some ugly (implicit) conversions from test_struct.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 14:32:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 13:32:47 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293543167.24.0.224529085081.issue10783@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, Victor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 14:40:20 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 28 Dec 2010 13:40:20 +0000
Subject: [issue10783] struct.pack() and Unicode strings
In-Reply-To: <1293480596.05.0.335729473125.issue10783@psf.upfronthosting.co.za>
Message-ID: <1293543620.36.0.905833794749.issue10783@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Thanks everyone for looking at this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10783>
_______________________________________

From report at bugs.python.org  Tue Dec 28 14:51:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 13:51:47 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293544307.01.0.624458175705.issue10348@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Informations about SysV semaphores:
 - functions: semget(), semop(), semctl(), ftok()
 - http://perldoc.perl.org/IPC/SysV.html
 - http://beej.us/guide/bgipc/output/html/multipage/semaphores.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Tue Dec 28 15:01:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 14:01:20 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293544880.74.0.840349332672.issue10348@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Examples of programs using SysV semaphores:

http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/src/jrd/isc_sync.cpp?revision=HEAD&view=markup
(Firebird, search "#ifdef USE_SYS5SEMAPHORE" sections)

https://github.com/mono/mono/blob/master/mono/io-layer/shared.c#L501
(Mono)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Tue Dec 28 15:33:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 28 Dec 2010 14:33:40 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293546820.39.0.472950512551.issue9333@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks for having a look.
Checked in with the suggested changes to r87539.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:02:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 28 Dec 2010 16:02:55 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293552175.41.0.324442917171.issue10759@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed this in r87542 in (py3k). unescape is undocumented helper method, so no docs are added.

There was already an issue ( Issue6662) on malformed charref handling and it is fixed.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:11:31 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 28 Dec 2010 16:11:31 +0000
Subject: [issue10759] HTMLParser.unescape() fails on HTML entities with
	incorrect syntax (e.g. &#hearts; )
In-Reply-To: <1293025868.1.0.668591972662.issue10759@psf.upfronthosting.co.za>
Message-ID: <1293552691.69.0.293115110611.issue10759@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

r87544 (release27-maint) and r87545 (release31-maint).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10759>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:16:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 28 Dec 2010 16:16:26 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1293552986.97.0.644150384315.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed backports:

r87540 (3.1)
r87541 (2.7)
r87546 (2.6)

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:17:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 16:17:49 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293553069.55.0.171305570602.issue10786@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
nosy: +michael.foord
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:27:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Dec 2010 16:27:51 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293553671.41.0.802765462572.issue10786@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

TextTestRunner is initialised with a stream to output messages on that defaults to sys.stderr. The correct way to redirect messages is to construct it with a different stream. 

If you want a redirectable stream then construct the runner with a stream that delegates operations to a 'backend stream' but allows you to redirect it.

Fixing TextTestRunner to dynamically lookup up sys.stderr would not be compatible with systems that redirect sys.stderr but *don't* expect this to prevent test run information from being output.

I suggest closing as wontfix.

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:34:33 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Dec 2010 16:34:33 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293554073.19.0.15953032141.issue10786@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Actually I can't see a good reason why not to just lookup the *current* sys.stderr at instantiation time instead of binding at import time as is the current behaviour.

Patch with tests will make it more likely that this change goes in sooner rather than later.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Tue Dec 28 17:48:38 2010
From: report at bugs.python.org (David Kremer)
Date: Tue, 28 Dec 2010 16:48:38 +0000
Subject: [issue10787] [random.gammavariate] Add the expression of the
	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>


New submission from David Kremer <david.kremer.dk at gmail.com>:

Could you please add the exact form of the distribution, because it's rather confusing in the current form.

In this url, the role of k and theta is precised with a formula :
[http://tinyurl.com/24jxfrk]*

It seems that in 
[http://docs.python.org/library/random.html#random.gammavariate] , alpha is playing the role of k and beta is playing the role of theta.

But it's still not clear, because one can confuse beta with 1/beta and vice et versa, like there is two usual representation for the gamma distribution [http://en.wikipedia.org/wiki/Gamma_distribution]

[http://docs.scipy.org/doc/numpy-1.5.x/reference/generated/numpy.random.gamma.html#numpy.random.gamma]*

Please update the documentation to avoid this ambiguity.

I provide an indicative patch which is updating the doc string in random.py

----------
assignee: docs at python
components: Documentation
files: patch_documentation_random.py.diff
keywords: patch
messages: 124803
nosy: David.Kremer, docs at python
priority: normal
severity: normal
status: open
title: [random.gammavariate] Add the expression of the distribution in a comprehensive form for random.gammavariate
versions: Python 2.7
Added file: http://bugs.python.org/file20181/patch_documentation_random.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10787>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:09:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 28 Dec 2010 17:09:16 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293556156.73.0.219190935453.issue9333@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Checked in a small doc update in r87547. Removes the part about os.symlink not being available, and mentions the OSError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:16:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 17:16:13 +0000
Subject: [issue6027] test_xmlrpc_net fails when the ISP returns "302 Found"
In-Reply-To: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za>
Message-ID: <1293556573.41.0.640082655904.issue6027@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 on simply removing this test. *.xmlrpc.com look(s) totally unmaintained.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6027>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:26:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 28 Dec 2010 17:26:52 +0000
Subject: [issue1772833] -q (quiet) option for python interpreter
Message-ID: <1293557212.44.0.211829537457.issue1772833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is it on purpose that no sys.flags attribute has been added for quiet?

----------
nosy: +eric.araujo
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772833>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:36:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 28 Dec 2010 17:36:02 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293557762.88.0.325512051818.issue10764@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I suggest this bug is superseded by #9878.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:36:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 17:36:15 +0000
Subject: [issue10788] test_logging failure
In-Reply-To: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>
Message-ID: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This on the Windows Server 2008 buildbot:

(http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x)

Re-running test 'test_logging' in verbose mode
test_flat (test.test_logging.BuiltinLevelsTest) ... FAIL
test_nested_explicit (test.test_logging.BuiltinLevelsTest) ... FAIL
test_nested_inherited (test.test_logging.BuiltinLevelsTest) ... FAIL
test_nested_with_virtual_parent (test.test_logging.BuiltinLevelsTest) ... FAIL
test_callable_filter (test.test_logging.BasicFilterTest) ... FAIL
test_filter (test.test_logging.BasicFilterTest) ... FAIL
test_handler_filter (test.test_logging.CustomLevelsAndFiltersTest) ... FAIL
test_logger_filter (test.test_logging.CustomLevelsAndFiltersTest) ... FAIL
test_specific_filters (test.test_logging.CustomLevelsAndFiltersTest) ... FAIL
test_flush (test.test_logging.MemoryHandlerTest) ... FAIL
test_config0_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config1_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config2_failure (test.test_logging.ConfigFileTest) ... FAIL
test_config3_failure (test.test_logging.ConfigFileTest) ... FAIL
test_config4_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config5_ok (test.test_logging.ConfigFileTest) ... FAIL
test_config6_ok (test.test_logging.ConfigFileTest) ... FAIL
test_output (test.test_logging.SocketHandlerTest) ... FAIL
test_persistent_loggers (test.test_logging.MemoryTest) ... FAIL
test_encoding_cyrillic_unicode (test.test_logging.EncodingTest) ... FAIL
test_encoding_plain_file (test.test_logging.EncodingTest) ... FAIL
test_warnings (test.test_logging.WarningsTest) ... FAIL
test_config0_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config11_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config12_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config13_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config1_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config2_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config2a_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config2b_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config3_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config4_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config4a_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config5_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config6_failure (test.test_logging.ConfigDictTest) ... FAIL
test_config7_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config_10_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config_8_ok (test.test_logging.ConfigDictTest) ... FAIL
test_config_9_ok (test.test_logging.ConfigDictTest) ... FAIL
test_listen_config_10_ok (test.test_logging.ConfigDictTest) ... FAIL
test_listen_config_1_ok (test.test_logging.ConfigDictTest) ... FAIL
test_manager_loggerclass (test.test_logging.ManagerTest) ... FAIL
test_braces (test.test_logging.FormatterTest) ... ok
test_dollars (test.test_logging.FormatterTest) ... ok
test_percent (test.test_logging.FormatterTest) ... ok
test_logrecord_class (test.test_logging.LogRecordFactoryTest) ... FAIL
test_child_loggers (test.test_logging.ChildLoggerTest) ... FAIL
test_queue_handler (test.test_logging.QueueHandlerTest) ... FAIL
test_file_created (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_rollover_filenames (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_should_not_rollover (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_should_rollover (test.test_logging.RotatingFileHandlerTest) ... FAIL
test_last_resort (test.test_logging.LastResortTest) ... FAIL

======================================================================
FAIL: test_flat (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_nested_explicit (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_nested_inherited (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_nested_with_virtual_parent (test.test_logging.BuiltinLevelsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_callable_filter (test.test_logging.BasicFilterTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_filter (test.test_logging.BasicFilterTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_handler_filter (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 411, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_logger_filter (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 411, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_specific_filters (test.test_logging.CustomLevelsAndFiltersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 411, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_flush (test.test_logging.MemoryHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 500, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config0_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config1_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2_failure (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config3_failure (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config4_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config5_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config6_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_output (test.test_logging.SocketHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 822, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_persistent_loggers (test.test_logging.MemoryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 868, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_encoding_cyrillic_unicode (test.test_logging.EncodingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_encoding_plain_file (test.test_logging.EncodingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_warnings (test.test_logging.WarningsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config0_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config11_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config12_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config13_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config1_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2a_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config2b_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config3_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config4_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config4a_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config5_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config6_failure (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config7_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config_10_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================Warning -- logging._handlerList was modified by test_logging
test test_logging failed -- multiple errors occurred

FAIL: test_config_8_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_config_9_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_listen_config_10_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_listen_config_1_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_manager_loggerclass (test.test_logging.ManagerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_logrecord_class (test.test_logging.LogRecordFactoryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1826, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_child_loggers (test.test_logging.ChildLoggerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_queue_handler (test.test_logging.QueueHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1851, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_file_created (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_rollover_filenames (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_should_not_rollover (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_should_rollover (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 1977, in setUp
    BaseTest.setUp(self)
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

======================================================================
FAIL: test_last_resort (test.test_logging.LastResortTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_logging.py", line 93, in setUp
    self.assertFalse(self.logger1.hasHandlers())
AssertionError: True is not false

----------------------------------------------------------------------

----------
assignee: vinay.sajip
components: Tests
messages: 124808
nosy: brian.curtin, georg.brandl, pitrou, vinay.sajip
priority: release blocker
severity: normal
status: open
title: test_logging failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10788>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:37:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 28 Dec 2010 17:37:37 +0000
Subject: [issue10774] test_logging leaves temp files
In-Reply-To: <1293385916.1.0.162939898354.issue10774@psf.upfronthosting.co.za>
Message-ID: <1293557857.12.0.145130356673.issue10774@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10774>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:52:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 28 Dec 2010 17:52:27 +0000
Subject: [issue10787] [random.gammavariate] Add the expression of the
	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293558747.95.0.803807117805.issue10787@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10787>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:55:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 28 Dec 2010 17:55:46 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293558946.51.0.243528070839.issue10764@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Avoid parsing pyconfig.h and Makefile by autogenerating extension module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Tue Dec 28 18:58:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 28 Dec 2010 17:58:18 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1293559098.22.0.959516776334.issue10764@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

No, issue 9878 can't be implemented for Python 2.7 whereas the issues other implementations have with sysconfig *could* still be resolved in 2.7 as a bugfix. (Specifically for IronPython on Mac OS X it would mean not assuming that being on a posix platform means there is a Makefile.)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Tue Dec 28 19:30:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 18:30:30 +0000
Subject: [issue1772833] -q (quiet) option for python interpreter
Message-ID: <1293561030.07.0.662153360061.issue1772833@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, pure ignorance -- should be fixed in r87549.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772833>
_______________________________________

From report at bugs.python.org  Tue Dec 28 20:08:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 19:08:43 +0000
Subject: [issue6027] test_xmlrpc_net fails when the ISP returns "302 Found"
In-Reply-To: <1242351266.25.0.645875354715.issue6027@psf.upfronthosting.co.za>
Message-ID: <1293563323.08.0.930614255697.issue6027@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 6533.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6027>
_______________________________________

From report at bugs.python.org  Tue Dec 28 20:11:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 Dec 2010 19:11:19 +0000
Subject: [issue9824] SimpleCookie should escape commas and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1293563479.67.0.915418905625.issue9824@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r87550.  Since the only application that would trip up would be one not using SimpleCookie to read SimpleCookie generated cookies *and* that doesn't implement unescaping (in which case it wasn't really handling SimpleCookie cookies, was it?), I went ahead and backported it to 3.1 in r87551 and 2.7 in r87552.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Tue Dec 28 20:57:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Dec 2010 19:57:35 +0000
Subject: [issue10738] webbrowser.py bug with Opera on Linux
In-Reply-To: <1292771123.61.0.59980527904.issue10738@psf.upfronthosting.co.za>
Message-ID: <1293566255.26.0.762054636287.issue10738@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.2,3.1,2.7: r87553, r87554, r87555

----------
assignee:  -> terry.reedy
components: +Library (Lib)
resolution:  -> fixed
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10738>
_______________________________________

From report at bugs.python.org  Tue Dec 28 21:05:55 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 28 Dec 2010 20:05:55 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293566755.07.0.746197329033.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101228a.zip is a new version of the regex module.

It now compiles the pattern quickly.

----------
Added file: http://bugs.python.org/file20182/issue2636-20101228a.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec 28 22:05:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 28 Dec 2010 21:05:11 +0000
Subject: [issue10766] optparse uses %s in gettext calls
In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>
Message-ID: <1293570311.18.0.865625364789.issue10766@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

argparse is not new if you consider that it?s present in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10766>
_______________________________________

From report at bugs.python.org  Tue Dec 28 22:15:13 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Tue, 28 Dec 2010 21:15:13 +0000
Subject: [issue10626] Bad interaction between test_logging and
	test_concurrent_futures
In-Reply-To: <1291470675.23.0.112557150968.issue10626@psf.upfronthosting.co.za>
Message-ID: <1293570913.11.0.741811305381.issue10626@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Fixed in r87556.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10626>
_______________________________________

From report at bugs.python.org  Tue Dec 28 22:31:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 28 Dec 2010 21:31:04 +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: <1293571864.93.0.112266347698.issue8618@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Looks like this might be an issue with the Windows Server 2008 build slave. I restarted it last night and a bunch of builds after that have failed due to this test.

----------
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8618>
_______________________________________

From report at bugs.python.org  Tue Dec 28 22:42:54 2010
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Dec 2010 21:42:54 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293572574.25.0.407430453891.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> Besides, if you are writing library code (as opposed to application
> code), you shouldn't care at all how tracebacks are displayed, should
> you?

I care when it lies:

During handling of the above exception, another exception occurred:

This is a blatant falsehood -- another exception did not occur, a different exception was raised.

Now, when another exception does actually occur, I'm all for the nested traceback, but if I'm raising a different one, why is this useful:

--> d.address
Traceback (most recent call last):
  File "nested_exceptions.py", line 7, in __getattr__
    return self.data[self.names.index(name)]
ValueError: tuple.index(x): x not in tuple

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "nested_exceptions.py", line 9, in __getattr__
    raise AttributeError("Attribute %s does not exist" % name)
AttributeError: Attribute address does not exist

?

Furthermore, I use my own library, and have no interest in seeing extra, completely unnecessary, and wrong (verbiage, anyway) traceback info -- not in my own libraries, nor in other's that I may be using.

Keep the nesting for when an exception actually occurs, not for when an exception is, under programmer control, being modified/changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 22:57:48 2010
From: report at bugs.python.org (Jacques Grove)
Date: Tue, 28 Dec 2010 21:57:48 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293573468.98.0.969938367021.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Thanks, issue2636-20101228a.zip also resolves my compilation speed issues I had on other (very) complex regexes.

Found this one:

re.search("(X.*?Y\s*){3}(X\s*)+AB:", "XY\nX Y\nX  Y\nXY\nXX AB:")

produces a search hit with stock python 2.6.5 regex library, but not with issue2636-20101228a.zip.

re.search("(X.*?Y\s*){3,}(X\s*)+AB:", "XY\nX Y\nX  Y\nXY\nXX AB:")

matches on both, however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Dec 28 22:58:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 21:58:18 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293572574.25.0.407430453891.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293573491.3700.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> During handling of the above exception, another exception occurred:
> 
> This is a blatant falsehood -- another exception did not occur, a
> different exception was raised.

This doesn't make any difference in any other context, so why would it
here? If only the above sentence is problematic, you can perhaps suggest
another one.

> Now, when another exception does actually occur, I'm all for the
> nested traceback, but if I'm raising a different one, why is this
> useful:

To me that's the same as asking why the full call stack is useful. In
some cases it is useful, in other cases it is distracting. Python
displays comprehensive information by default. As I said, this can be
tweaked using the traceback module.

By the way, this is all described in detail in a PEP:
http://www.python.org/dev/peps/pep-3134/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 23:14:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 28 Dec 2010 22:14:21 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293574461.39.0.833451634478.issue10785@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I like the idea, but I don't like the trend that parser code continues to diverge from pgen.  I understand that most of the Python runtime is not available to pgen, but maybe a more elegant solution than changing the type conditional on PGEN can be found.  For example, maybe filename could be decoded from FS encoding to UTF-8?

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Tue Dec 28 23:45:58 2010
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 28 Dec 2010 22:45:58 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293576358.37.0.332952116724.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

>> During handling of the above exception, another exception occurred:
>> 
>> This is a blatant falsehood -- another exception did not occur, a
>> different exception was raised.
> 
> This doesn't make any difference in any other context, so why would it
> here?

I'm not sure I understand what you are saying -- could you rephrase?


> By the way, this is all described in detail in a PEP:
> http://www.python.org/dev/peps/pep-3134/

Yes, I know -- and from the PEP:

Rationale

    The Python-Dev discussions revealed interest in exception chaining
    for two quite different purposes.  To handle the unexpected raising
    of a secondary exception, the exception must be retained implicitly.
    To support intentional translation of an exception, there must be a
    way to chain exceptions explicitly.  This PEP addresses both.

Open Issue: Suppressing Context

    As written, this PEP makes it impossible to suppress '__context__',
    since setting exc.__context__ to None in an 'except' or 'finally'
    clause will only result in it being set again when exc is raised.

The two motivations are excellent, and I have no issue with them; what I have issue with is that it is no longer possible to discard previous context.  If I want to change the error message, I can use

        except ValueError as exc:
            raise AttributeError("blah") from exc

and then get

  The above exception was the direct cause of the following exception

I would also like to see:

        except ValueError as exc:
            raise AttributeError("blah") with exc

to get 

  During handling of the above exception, another exception occurred

which would be the same as:

        1/0

to get

  During handling of the above exception, another exception occurred

and, finally, if all I have is 

        except ValueError as exc:
            raise AttributeError("blah")

I just get the normal, previous context free, traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Tue Dec 28 23:49:00 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 28 Dec 2010 22:49:00 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293576540.79.0.369698290946.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here is a tentative start on this.  (css_v1.diff)

The css file is much better.  It's shorter, simpler and validated.

The header and navbar panel use it in the new server.

Added a markup call to the topic page contents.  (The same markup call is already used for the doc strings.)

Extra items in the css are what I come up with from testing different ways of doing things.

----------
keywords: +patch
Added file: http://bugs.python.org/file20183/css_v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Wed Dec 29 00:15:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 23:15:15 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293578115.64.0.188264696571.issue10785@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> maybe a more elegant solution than changing the type conditional 
> on PGEN can be found

In pgen, the filename is only used to display the following warning, in indenterror():

   <filename>: inconsistent use of tabs and spaces in indentation

In pratical, this warning never occurs on Grammar/Grammar: this file doesn't use indentation at all, only continuation lines.

A better solution is maybe just to drop the filename for pgen. Anyway, pgen only compiles *one* file (Grammar/Grammar), so we don't need the input filename ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Wed Dec 29 00:16:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 23:16:40 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293578200.7.0.323306313515.issue10785@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

When testing my patch, I found and fixed two bugs in pgen:
 - r87557: PGEN was not defined to compile pgenmain.c and printgrammar.c
 - r87558: pgen error was ignored on "make Parser/pgen.stamp" (when executing pgen to compile the grammar)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Wed Dec 29 00:32:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 23:32:49 +0000
Subject: [issue10785] parser: store the filename as an unicode object
In-Reply-To: <1293504022.51.0.668746175929.issue10785@psf.upfronthosting.co.za>
Message-ID: <1293579169.57.0.959486049385.issue10785@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 2 of the patch:
 - remove filename attribute from perrdetail and tok_state structure in PGEN mode, and add a comment to explain why
 - rename filename_obj to filename
 - indenterror() no longer print the input filename in PGEN mode

----------
Added file: http://bugs.python.org/file20184/parser_filename_obj-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10785>
_______________________________________

From report at bugs.python.org  Wed Dec 29 00:50:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Dec 2010 23:50:09 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1293580209.07.0.00463849097454.issue5672@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/issue5672>
_______________________________________

From report at bugs.python.org  Wed Dec 29 00:54:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Dec 2010 23:54:19 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293576358.37.0.332952116724.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293580441.3700.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> and, finally, if all I have is 
> 
>         except ValueError as exc:
>             raise AttributeError("blah")
> 
> I just get the normal, previous context free, traceback.

And what if the exception is raised from a subroutine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 01:06:18 2010
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 29 Dec 2010 00:06:18 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293581178.52.0.123219068672.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> And what if the exception is raised from a subroutine?

Well, if I have it surrounded by a try/except block, presumably I'm aware that an exception could be raised.  ;)

And if I'm aware that an exception could be raised, it may also be possible that I want to change the exception -- leading to the three possibilities I described earlier.  

Looking through my dbf module, most of those re-raises I'll be changing to use the raise ... from ... syntax, but there are still a couple places where it makes no sense to have the extra nested information available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 01:14:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Dec 2010 00:14:47 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293581687.47.0.923087174892.issue10348@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #5725.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Wed Dec 29 01:15:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Dec 2010 00:15:22 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293581178.52.0.123219068672.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293581718.3700.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > And what if the exception is raised from a subroutine?
> 
> Well, if I have it surrounded by a try/except block, presumably I'm
> aware that an exception could be raised.  ;)

I'm talking about the exception raised from the except block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 01:19:38 2010
From: report at bugs.python.org (Jacques Grove)
Date: Wed, 29 Dec 2010 00:19:38 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293581978.77.0.394570353143.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

Here is a somewhat crazy pattern (slimmed down from something much larger and more complex, which didn't finish compiling even after several minutes): 

re.compile("(?:(?:[23][0-9]|3[79]|0?[1-9])(?:[Aa][Aa]|[Aa][Aa]|[Aa][Aa])??(?:[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}|[Aa]{4}|[Aa]{4}|[Aa]{3}(?:[Aa]{3})?|[Aa]{3}(?:[Aa](?:[Aa]{5})?)?|[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa]{5})?)|(?:[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}|[Aa]{4}|[Aa]{4}|[Aa]{3}(?:[Aa]{3})?|[Aa]{3}(?:[Aa](?:[Aa]{5})?)?|[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa]{5})?)(?:(?:[\-\s\.,>/]){0,4}?)(?:[23][0-9]|3[79]|0?[1-9])(?:[Aa][Aa]|[Aa][Aa]|[Aa][Aa])??)\W*(?:[79][0-9]|2[0-4]|\d)(?:[\.:Aa])?(?:[0-5][0-9])\W*(?:(?:[Aa]{3}(?:[Aa]{3})?|[Aa]{3}(?:[Aa](?:[Aa]{3})?)?|[Aa]{3}(?:[Aa]{5}[Aa])?|[Aa]{3}(?:[Aa](?:[Aa]{4})?)?|[Aa]{3}(?:[Aa]{3})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa]{3})?)|(?:[Aa][Aa](?:[Aa](?:[Aa]{3})?)?|[Aa][Aa](?:[Aa](?:[Aa](?:[Aa](?:[Aa]{3})?)?)?)?|[Aa][Aa](?:[Aa](?:[Aa](?:[Aa]{4})?)?)?|[Aa][Aa](?:[Aa](?:[Aa]{3}(?:[Aa](?:[Aa]{3})?)?)?)?|[Aa][Aa](?:[Aa](?:[Aa](?:[Aa]{3})?)?)?|[Aa][Aa](?:[Aa](?:[Aa](?:[Aa]{3})?)?)?|[Aa]{3}(?:[Aa](?:[Aa](?:[Aa]{4})?)?)?|[Aa][Aa](?:[Aa](?:[Aa](?:[Aa]{3})?)?)?))\s*(\-\s*)?(?:(?:[23][0-9]|3[79]|0?[1-9])(?:[Aa][Aa]|[Aa][Aa]|[Aa][Aa])??(?:(?:[\-\s\.,>/]){0,4}?)(?:[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}|[Aa]{4}|[Aa]{4}|[Aa]{3}(?:[Aa]{3})?|[Aa]{3}(?:[Aa](?:[Aa]{5})?)?|[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa]{5})?)|(?:[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}(?:[Aa][Aa])?|[Aa]{3}|[Aa]{4}|[Aa]{4}|[Aa]{3}(?:[Aa]{3})?|[Aa]{3}(?:[Aa](?:[Aa]{5})?)?|[Aa]{3}(?:[Aa]{4})?|[Aa]{3}(?:[Aa]{5})?|[Aa]{3}(?:[Aa]{5})?)(?:(?:[\-\s\.,>/]){0,4}?)(?:[23][0-9]|3[79]|0?[1-9])(?:[Aa][Aa]|[Aa][Aa]|[Aa][Aa])??)(?:(?:(?:[\-\s\.,>/]){0,4}?)(?:(?:68)?[7-9]\d|(?:2[79])?\d{2}))?\W*(?:[79][0-9]|2[0-4]|\d)(?:[\.:Aa])?(?:[0-5][0-9])")


Runs about 10.5 seconds on my machine with issue2636-20101228a.zip, less than 0.03 seconds with stock Python 2.6.5 regex engine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Dec 29 01:42:25 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 29 Dec 2010 00:42:25 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293583345.13.0.554621046718.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101229.zip is a new version of the regex module.

It now compiles the pattern quickly.

----------
Added file: http://bugs.python.org/file20185/issue2636-20101229.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:10:48 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 29 Dec 2010 01:10:48 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293585048.59.0.737365346552.issue9333@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Tests now fail on windows XP:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/3874/steps/test/logs/stdio

os.symlink() may raise NotImplementedError, and test.support.can_symlink() should catch it.

----------
stage: committed/rejected -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:15:26 2010
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 29 Dec 2010 01:15:26 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293585326.55.0.268905833222.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> I'm talking about the exception raised from the except block.

So was I -- why should this:

try:
    x = y / z
except ZeroDivisionError as exc:
    raise InvalidInput()

be different from this:

try:
    x = divide_and_conquer(y, z)
except ZeroDivisionError as exc:
    raise InvalidInput()

?

In both cases I want to discard the previous exception, and raise my own in its place (without the nesting, in this example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:23:26 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 29 Dec 2010 01:23:26 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1293585806.86.0.446616973651.issue5672@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> If somebody would provide a patch that adds prctl to the posix module,
> that would be fine with me - we have a long tradition of exposing all
> available system calls if somebody wants them.

Just for the record, I was about to try to do this, when I realized that exposing prctl requires expecting a variable number of arguments with variable types.
It turns out providing a Python wrapper for such a kind of C API is just a pain.
There's an implementation though, handling 2 args only (instead of 5):
https://github.com/seveas/python-prctl/blob/master/_prctlmodule.c#L9
Considering that this also Linux-only, I don't think it really worths the effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:24:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Dec 2010 01:24:47 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293585887.19.0.804966107626.issue10348@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also http://semanchuk.com/philip/sysv_ipc/: "System V IPC for Python - Semaphores, Shared Memory and Message Queues"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:25:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 01:25:44 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290895400.38.0.59035357378.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=KcpEbb4FD5M0xmF45Khtbfr=JzAUGLP13W41=@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Nov 27, 2010 at 5:03 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> ?* this version should be slightly faster and is also easier to read:
>
> #define Py_UCS4_READ_CODE_POINT(ptr, end) \
..
> ? ? ?Py_UNICODE_JOIN_SURROGATES((ptr)++, (ptr)++) : \
..
> ? I haven't tested it, but you get the idea.

I don't think C guarantees the order of evaluation of the operands in
bitwise expressions such as the expansion of the JOIN_SURROGATES
macro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:46:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Dec 2010 01:46:04 +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: <1293587164.97.0.671111038441.issue8654@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________

From report at bugs.python.org  Wed Dec 29 02:46:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Dec 2010 01:46:18 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293587178.14.0.338165765359.issue6210@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 03:05:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Dec 2010 02:05:44 +0000
Subject: [issue9333] Expose a way to enable os.symlink on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1293588344.2.0.628805352525.issue9333@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Oops, sorry. Fixed in r87561.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9333>
_______________________________________

From report at bugs.python.org  Wed Dec 29 03:06:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Dec 2010 02:06:48 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1293585806.86.0.446616973651.issue5672@psf.upfronthosting.co.za>
Message-ID: <4D1A97B5.1020204@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Just for the record, I was about to try to do this, when I realized that exposing prctl requires expecting a variable number of arguments with variable types.
> It turns out providing a Python wrapper for such a kind of C API is just a pain.
> There's an implementation though, handling 2 args only (instead of 5):
> https://github.com/seveas/python-prctl/blob/master/_prctlmodule.c#L9
> Considering that this also Linux-only, I don't think it really worths the effort.

It's actually simpler than you think: I don't think any of the existing
controls uses arg4 and arg5. PR_MCE_KILL uses arg3, though. prctl is
really a set of system calls, and should be wrapped as such: each
control needs to be supported specifically. However, several of them
are similar, i.e. take either no argument, or have

Whether it's worth supporting it, I don't know. I stand by my original
proposition: if somebody would contribute this, I'd be in favor of
including it. I'm unlikely to write it on my own from scratch, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Dec 29 05:26:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 04:26:04 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293596764.77.0.771588847487.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch for commit review.  I added an underscore prefix to all new macros.  This way I am not introducing new features and we will have a full release cycle to come up with better names.  i would just note that "next" terminology is consistent with PyDict_Next and _PySet_NextEntry.  The latter suggests that Py_UNICODE_NEXT_UCS4 may be a better choice.

----------
assignee: lemburg -> belopolsky
stage: patch review -> commit review
Added file: http://bugs.python.org/file20186/issue10542.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 05:31:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Dec 2010 04:31:01 +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: <1293597061.09.0.405100484486.issue8618@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This isn't failing in manual runs of regrtest -uall on that machine.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8618>
_______________________________________

From report at bugs.python.org  Wed Dec 29 07:32:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 29 Dec 2010 06:32:34 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1293604354.06.0.551782806394.issue10753@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

r87564 (py3k), r87565 (release31-maint) and r87566 (release27-maint).

Just a Note.

These kind of minor changes have many a times resulted in regression for developers who relied upon previous bad behavior.  I have added NEWS to explain this change clearly and hopefully it gets noticed and accommodate this change in their code.

Thanks.

----------
assignee:  -> orsenthil
keywords: +patch
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
Added file: http://bugs.python.org/file20187/issue10753.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Wed Dec 29 09:46:58 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Dec 2010 08:46:58 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293612418.9.0.877068183634.issue6210@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, the context must always be included unless explicitly suppressed. The interpreter can't reliably tell the difference between a raise statement in the current exception handler and one buried somewhere inside a nested function call. The whole point is to give developers a hint as to how to trigger the broken error handling code, which only works if the default behaviour is to provide the additional information.

Being able to suppress the context *is* a valid feature request, but one that will now need to wait until Python 3.3. In the meantime, sys.excepthook + the traceback module + PYTHONSTARTUP allows individual users to modify the interactive prompt to exhibit whatever exception display behaviour they like, and applications can do the same thing in their __main__module (likely via a context manager retrieved from a utility module).

----------
keywords: +after moratorium
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 09:53:25 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Dec 2010 08:53:25 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293612805.32.0.935262203286.issue6210@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For "can't tell" in my previous message, read "we aren't going to impose the requirement to be able to tell if an exception is being raised directly in the current exception handler as a feature of conforming Python implementations". We probably *could* tell the difference in CPython if we really wanted to.

Even without considering that aspect, it would also be seriously odd if putting the exception raising into a helper function suddenly caused context information to be included that was otherwise implicitly suppressed. Much better to correctly support explicit suppression of the context as discussed earlier in the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 10:15:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Dec 2010 09:15:44 +0000
Subject: [issue10787] [random.gammavariate] Add the expression of the
	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293614144.44.0.927049050398.issue10787@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/issue10787>
_______________________________________

From report at bugs.python.org  Wed Dec 29 10:19:38 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Wed, 29 Dec 2010 09:19:38 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <4D1A97B5.1020204@v.loewis.de>
Message-ID: <AANLkTi=z7qjDmp92sWXAESsRcJ5zmS=VNGzP1=1NNEOF@mail.gmail.com>


Floris Bruynooghe <floris.bruynooghe at gmail.com> added the comment:

There are actually a few implementations on pypi, just search for
prctl.  At least one of them is pretty decent IIRC but I can't
remember which one I looked at in detail before.  Anyway, they would
certainly be a reasonable starting point for python inclusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5672>
_______________________________________

From report at bugs.python.org  Wed Dec 29 10:20:24 2010
From: report at bugs.python.org (Matt Selsky)
Date: Wed, 29 Dec 2010 09:20:24 +0000
Subject: [issue9742] Python 2.7: math module fails to build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1293614424.39.0.562214787261.issue9742@psf.upfronthosting.co.za>


Changes by Matt Selsky <selsky at gmail.com>:


----------
nosy: +Matt.Selsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Wed Dec 29 11:40:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Dec 2010 10:40:09 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293585326.55.0.268905833222.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293619203.3709.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 29 d?cembre 2010 ? 01:15 +0000, Ethan Furman a ?crit :
> Ethan Furman <ethan at stoneleaf.us> added the comment:
> 
> > I'm talking about the exception raised from the except block.
> 
> So was I -- why should this:
> 
> try:
>     x = y / z
> except ZeroDivisionError as exc:
>     raise InvalidInput()
> 
> be different from this:
> 
> try:
>     x = divide_and_conquer(y, z)

I said the *except* block, not the *try* block ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 13:19:59 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 29 Dec 2010 12:19:59 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1293596764.77.0.771588847487.issue10542@psf.upfronthosting.co.za>
Message-ID: <4D1B2767.30209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I am attaching a patch for commit review.  I added an underscore prefix to all new macros.  This way I am not introducing new features and we will have a full release cycle to come up with better names.  i would just note that "next" terminology is consistent with PyDict_Next and _PySet_NextEntry.  The latter suggests that Py_UNICODE_NEXT_UCS4 may be a better choice.

I don't think this should go into 3.2. The macros have the potential
of subtly changing Python semantics when used in places that previously
did not support auto-joining surrogates. Let's wait for 3.3 with the
change.

Some comments:

* The macros still need some more attention to enhance their performance.

* For consistency, I'd choose names Py_UNICODE_READ_NEXT()
  and Py_UNICODE_WRITE_NEXT() instead of Py_UNICODE_NEXT() and
  Py_UNICODE_PUT_NEXT().

* Py_UNICODE_JOIN_SURROGATES() either needs to go away completely
  (and be integrated straight into the other macros), or be renamed
  to Py_UCS4_JOIN_SURROGATES(), since it doesn't return Py_UNICODE
  values

* The macros need to be carefully documented, both in unicodeobject.h
  and the general docs.

* Your _Py_UNICODE_PUT_NEXT() implementation is missing a few casts
  to turn ch into a Py_UNICODE/Py_UCS4 value.

* Same for your _Py_UNICODE_NEXT() to make sure that the return
  value is indeed a Py_UNICODE value.

* In general, we should probably be clear on the allowed input
  and define the output types in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 15:18:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 14:18:36 +0000
Subject: [issue10753] request_uri method of wsgiref module does not support
	RFC1808 params.
In-Reply-To: <1292974948.23.0.113503342061.issue10753@psf.upfronthosting.co.za>
Message-ID: <1293632316.53.0.12395906231.issue10753@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In this case I think it is safe enough, since it only results in the ;,= not getting encoded.  If an application were doing anything with the encoded chars, it would probably be decoding them, and now that step will simply become a noop.  Of course, breakage is always possible, but this change seems worth what appears to be a relatively small risk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10753>
_______________________________________

From report at bugs.python.org  Wed Dec 29 15:41:26 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Wed, 29 Dec 2010 14:41:26 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1293633686.54.0.241463628709.issue7511@psf.upfronthosting.co.za>


Thorsten Behrens <sbehrens at gmx.li> added the comment:

Confirmed that this issue exists on Python 3.1 and 3.2b2. The exception thrown presents as:

ValueError: ['path', 'include', 'lib']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Wed Dec 29 16:00:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Dec 2010 15:00:53 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293634853.12.0.7338873519.issue10542@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Let's wait for 3.3 with the change.

Definitely.

----------
nosy: +georg.brandl
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 16:58:58 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Dec 2010 15:58:58 +0000
Subject: [issue10788] test_logging failure
In-Reply-To: <1293557775.34.0.401807724335.issue10788@psf.upfronthosting.co.za>
Message-ID: <1293638338.21.0.135820539008.issue10788@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

These failures in build 363 (using r87563) would occur if some stdlib code added a handler to the root logger before the start of test_logging. I see that build 364 doesn't show this failure, and it's testing r87564. From what I can see, the only changes in r87564 over r87563 are some wsgiref-related changes by Senthil - there's no logging interaction that I can see.

I had a look at some of the other buildbots and I haven't seen this problem there.

It could be timing related in some way but at this point I'm just scratching my head. Suggestions gratefully received :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10788>
_______________________________________

From report at bugs.python.org  Wed Dec 29 17:28:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 16:28:53 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1293634853.12.0.7338873519.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=g4cJSPsKCdAoW4DV+QNKBrywt7qdiDZF9vDby@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 29, 2010 at 10:00 AM, Georg Brandl <report at bugs.python.org> wrote:
..
>
>> Let's wait for 3.3 with the change.
>
> Definitely.

Does this also mean that the numerous surrogates related bugs should
wait until 3.3 as well? (See issues #9200 and #10521.)

This patch was just a stepping stone for the bug fixes.   I
deliberately kept the code changes to the minimum sufficient to
demonstrate and test the new macros.  I would not mind restricting the
patch further by limiting it to the header file changes so that the
macros can be used to fix bugs.  Fixing the bugs in the old verbose
style does not seem feasible.

Note that surrogate bugs are not as exotic as they seem.  For example,
on a wide build I can do

42

but on a narrow build,

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    ? = 42
       ^
SyntaxError: invalid character in identifier

So at the moment, narrow and wide builds implement two different languages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 17:36:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Dec 2010 16:36:03 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293640563.6.0.163107906681.issue10542@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That bug already strikes me as quite exotic.

You need to at least address Marc-Andre's remarks, and to give an overview of what else you'd like to change as well, and how this could affect semantics.

Remember that the next release is already a release candidate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:12:19 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 29 Dec 2010 17:12:19 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293642739.93.0.780838243128.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

The HtmlDoc class has methods that take colors. Can this be changed or does it need to be depreciated first? 

    def heading(self, title, fgcol, bgcol, extras=''):
        """Format a page heading."""
        return '''
<table width="100%%" cellspacing=0 cellpadding=2 border=0 summary="heading">
<tr bgcolor="%s">
<td valign=bottom>&nbsp;<br>
<font color="%s" face="helvetica, arial">&nbsp;<br>%s</font></td
><td align=right valign=bottom
><font color="%s" face="helvetica, arial">%s</font></td></tr></table>
    ''' % (bgcol, fgcol, title, fgcol, extras or '&nbsp;')

For the interactive server, I can override these methods with no problem, but the generated docs won't benefit from this until the HtmlDoc class is replaced.  Any suggestions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:14:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Dec 2010 17:14:35 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293642875.58.0.326504304826.issue10716@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, you could reuse these arguments to mean CSS classes, and have styles like ".red { color: red }" :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:29:58 2010
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 29 Dec 2010 17:29:58 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293643798.16.0.524910862184.issue6210@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

> I said the *except* block, not the *try* block ;)

Ah.  So you did.

Okay, if I'm understanding correctly, the scenario you are talking about involves the code in the except block calling some other function, and that other function is raising an exception...  seems unlikely that this would be a case of transforming one exception into another, therefore the raise should not suppress the context by default...  okay, I'll concede the point.

Looks like the best option, then, is Nick's idea of the .no_context() method on exceptions.

----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:30:24 2010
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 29 Dec 2010 17:30:24 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293643824.8.0.347362221118.issue6210@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:36:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 17:36:17 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <4D1B2767.30209@egenix.com>
Message-ID: <AANLkTinUhFG=mihzLv+xfqX2xrpc-ke1Gq-8wYCqt6pT@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 29, 2010 at 7:19 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> * The macros still need some more attention to enhance their performance.
>
Although I made your suggested change from '-' to '&', I seriously
doubt that this would make any difference on modern CPUs.  Why do you
think these macros are performance critical?  Users with lots of
supplementary characters in their files are probably better off with a
wide build where Py_UNICODE_NEXT() is just *ptr++ and can hardly be
further optimized.  Higher performance algorithms are possible, but
those should probably do some loop unrolling and/or process more than
one character at a time.  At this point, however it is too soon to
worry about optimization before we even know where these macros will
be used.

> * For consistency, I'd choose names Py_UNICODE_READ_NEXT()
> ?and Py_UNICODE_WRITE_NEXT() instead of Py_UNICODE_NEXT() and
> ?Py_UNICODE_PUT_NEXT().
>

I would leave it for you and Raymond to reach a consensus.  My
understanding is that Raymond does not want "next" in the name, so
your suggestion still conflicts with that.  I would mildly prefer
GET/PUT over READ/WRITE because the latter suggests multiple
characters.

As discussed before, the macro prefix does not imply the return value.
 Compare this to Py_UNICODE_ISSPACE() and friends or pretty much any
other Py_UNICODE_ macro.   Note that I added a leading underscore to
Py_UNICODE_JOIN_SURROGATES and other new macros, so there is no
immediate pressure to get the names perfect.

> * The macros need to be carefully documented, both in unicodeobject.h
> ?and the general docs.
>

I've added a description above _Py_UNICODE_*NEXT macros.  I would
really like to see these macros in private use for a while before they
are published for general audience.  I'll add a comment describing
_Py_UNICODE_JOIN_SURROGATES.  The remaining macros seem to be fairly
self-explanatory (unlike, say Py_UNICODE_ISDIGIT or Py_UNICODE_ISTITLE
which are not documented in unicodeobject.h.)

Explicit downcasts would probably make sense, for example *(ptr)++ =
(Py_UNICODE)ch instead of *(ptr)++ = ch, but I don't think we need
explicit casts say in Py_UCS4 code = (ch) - 0x10000; where they can
mask coding errors.

I also looked for the use of casts elsewhere in unicodeobject.h and
the following does not look right:

#define Py_UNICODE_ISSPACE(ch) \
    ((ch) < 128U ? _Py_ascii_whitespace[(ch)] : _PyUnicode_IsWhitespace(ch))

It looks like this won't work right if ch is a signed char.

> * Same for your _Py_UNICODE_NEXT() to make sure that the return
> ?value is indeed a Py_UNICODE value.
>

The return value of _Py_UNICODE_NEXT()  is *not* Py_UNICODE, it is
Py_UCS4 and as far as I can see, every conditional branch in narrow
case has an explicit cast.  In the wide case, I don't think we want an
explicit cast because ptr should already be Py_UCS4* and if it is not,
it may be a coding error that we don't want to mask.

> * In general, we should probably be clear on the allowed input
> ?and define the output types in the documentation.

I agree.  I'll add a note that ptr and end should be Py_UNICODE*.  I
am not sure what we should say about ch argument.  If we add casts,
the macro will accept anything, but we should probably document it as
expecting Py_UCS4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:41:18 2010
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 29 Dec 2010 17:41:18 +0000
Subject: [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>


New submission from Jyrki Pulliainen <jyrki at dywypi.org>:

In threading module, the Lock.acquire documentation is misleading. The signature suggests that the blocking can be given as a keyword argument but that would lead to an TypeError, as thread.lock.acquire does not accept keyword arguments.

The signature in documentation should be formatted as in thread.lock.acquire.

----------
assignee: docs at python
components: Documentation
messages: 124861
nosy: Jyrki.Pulliainen, docs at python
priority: normal
severity: normal
status: open
title: Lock.acquire documentation is misleading
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:45:30 2010
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 29 Dec 2010 17:45:30 +0000
Subject: [issue5725] process SysV-Semaphore support
In-Reply-To: <1239254455.57.0.547868960031.issue5725@psf.upfronthosting.co.za>
Message-ID: <1293644730.07.0.940534617166.issue5725@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5725>
_______________________________________

From report at bugs.python.org  Wed Dec 29 18:47:20 2010
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 29 Dec 2010 17:47:20 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1293644840.46.0.581241786531.issue10348@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Adding, or moving, to SYSV semaphores is very low on the list of things to do. If someone were to provide a patch, I'm sure we could consider it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Wed Dec 29 19:23:11 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 29 Dec 2010 18:23:11 +0000
Subject: [issue10716] Modernize pydoc to use CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1293646991.27.0.487355831031.issue10716@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

It may be useful to change those to 'id=' and 'class=' if possible.

It isn't clear to me how much of pydoc is still part of the public api in python 3.x.  pydoc.__all__ is set only to ['help'].  

Entering help(pydoc) just gives the basic help and command line arguments along with.

DATA
    __all__ = ['help']
    help = <pydoc.Helper instance>

There is nothing in the official (online) docs on importing pydoc or any of it's classes or methods.  

But dir(pydoc) shows all the methods, and the HTMLDoc class is still importable even though they aren't listed in __all__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Wed Dec 29 19:31:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 18:31:30 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <4CF18525.1050103@egenix.com>
Message-ID: <AANLkTi=-AX41M4RRv4K047obyrF0NXqLGhnLpXCzdi-S@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Nov 27, 2010 at 5:24 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> Perhaps we should allow ord() to work on surrogates in
> UCS4 builds as well. That would reduce the number of
> surprises.
>

This is an interesting idea, however, having surrogates in UCS4 builds
will sooner or later lead to surprises such as

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in
position 0: surrogates not allowed

I though UCS4 (or more properly, UTF-32) did not allow encoding of
surrogate code points.

It is somewhat bothersome that a valid string literal such as
'\uD800\uDC00' in narrow build is subtly invalid in wide build.  It
would probably be better if  '\uD800\uDC00'  was either rejected on a
wide build, or interpreted as a single character so that

True

on any build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 19:38:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 18:38:23 +0000
Subject: [issue10790] Header.append's charset logic is bogus,
	'shift_jis' and "euc_jp' don't work as charsets
In-Reply-To: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>
Message-ID: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Working on issue 10686, I've discovered that the logic for charset conversion in email.header.Header.append is bogus.  It happens to work for most charsets because for most charsets the input codec and the output codec are the same.  For shift_jis and euc_jp, however, this is not the case.

The attached patch fixes the logic and provides a test.

The logic is still not quite correct, since the 'errors' parameter should not be passed to the 'encode' test call, because the errors parameter is not passed to the encode call when the actual encoding is done in the Header.encode method.  If that call were fixed in this patch, one of the email tests would fail that currently passes.  However, if a 'Header.encode' call were made in that test, the encode call would fail.  Fixing that will require resolving issue 10686.

----------
assignee: r.david.murray
files: header_append.patch
keywords: patch
messages: 124865
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Header.append's charset logic is bogus, 'shift_jis' and "euc_jp' don't work as charsets
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20188/header_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10790>
_______________________________________

From report at bugs.python.org  Wed Dec 29 19:40:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 18:40:17 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293648017.99.0.446474539943.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The example in my previous message should have been:

>>> '\U00010000' == '\uD800\uDC00'
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 19:42:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 18:42:44 +0000
Subject: [issue10790] Header.append's charset logic is bogus,
	'shift_jis' and "euc_jp' don't work as charsets
In-Reply-To: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>
Message-ID: <1293648164.79.0.86957613392.issue10790@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10790>
_______________________________________

From report at bugs.python.org  Wed Dec 29 19:55:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 18:55:55 +0000
Subject: [issue10790] Header.append's charset logic is bogus,
	'shift_jis' and "euc_jp' don't work as charsets
In-Reply-To: <1293647903.09.0.559364426725.issue10790@psf.upfronthosting.co.za>
Message-ID: <1293648955.81.0.253419563159.issue10790@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Updated patch that also fixes the docs.

----------
Added file: http://bugs.python.org/file20189/header_append.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10790>
_______________________________________

From report at bugs.python.org  Wed Dec 29 20:26:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 19:26:19 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1293640563.6.0.163107906681.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTikiPRx62szpf3H6VnQ3ZqA++3fv9CH9h2HKVZu+@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 29, 2010 at 11:36 AM, Georg Brandl <report at bugs.python.org> wrote:
..
> That bug already strikes me as quite exotic.
>
Would it look as exotic if presented like this?

  File "<stdin>", line 1
    ? = 5
       ^
SyntaxError: invalid character in identifier
(works on a wide build)

Note that with few exceptions, pretty much anything you can do with
supplementary characters will produce different results in wide and
narrow builds.  This includes all character type methods (isalpha,
isdigit, etc.), transformations such as case folding or normalization,
text formatting, etc, etc.

When I suggested on python-dev that supplementary character support on
narrow builds is not worth violating fundamental invariants such as
len(chr(i)) == 1, pretty much everyone said that Python should support
full Unicode regardless of build.  When it comes to fixing specific
differences between builds, I hear that these differences are not
important because no one is using supplementary characters.

This example is less exotic than say str.center() or str.swapcase()
not because it involves less exotic characters - all non-BMP
characters are exotic by definition - but because it involves the core
definition of the Python language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 20:27:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 19:27:47 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293650867.63.0.660436876358.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I should stop using e-mail to reply to bug reports!  The mangled example was

>>> ? = 5
  File "<stdin>", line 1
    ? = 5
       ^
SyntaxError: invalid character in identifier

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 20:30:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 19:30:55 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293651055.12.0.383441811004.issue10542@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file20190/issue10542a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 20:53:54 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 29 Dec 2010 19:53:54 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

Is something like this supposed to work:

>>> import gzip
>>> import io
>>> f = io.TextIOWrapper(gzip.open("foo.gz"),encoding='ascii'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: readable

In a nutshell--reading a .gz file as text.

----------
messages: 124870
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Wrapping TextIOWrapper around gzip files
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 20:55:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 29 Dec 2010 19:55:19 +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: <1293652519.14.0.550252382181.issue8618@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Looks like whatever caused this is now gone.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8618>
_______________________________________

From report at bugs.python.org  Wed Dec 29 21:01:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Dec 2010 20:01:42 +0000
Subject: [issue10792] Compile() and 'Windows/Mac newlines'
In-Reply-To: <1293652902.05.0.92926379276.issue10792@psf.upfronthosting.co.za>
Message-ID: <1293652902.05.0.92926379276.issue10792@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In python-list thread "Does Python 3.1 accept \r\n in compile()?"
jmfauth notes that
compile('print(999)\r\n', '<in>', 'exec')
works in 2.7 but not 3.1 (and 3.2 not checked) because 3.1 sees '\r' as
SyntaxError.

I started to respond that this is part of Py3 cleanup with newlines converted on input and back-compatibility with ancient Python not needed. Then I saw in 3.2 manual

"Changed in version 3.2: Allowed use of Windows and Mac newlines. ..."

However, above gives same error. Should "Allowed use of Windows and Mac newlines." be deleted? What else could it mean other than use of '\r' or '\r\n'?

The note was added in r76232 which is a forward port of r76230
"fix several compile() issues by translating newlines in the tokenizer"
by B. Peterson. Is Windows/Mac part just not applicable to 3.2?

----------
assignee: benjamin.peterson
components: Documentation
messages: 124872
nosy: benjamin.peterson, terry.reedy
priority: normal
severity: normal
status: open
title: Compile() and 'Windows/Mac newlines'
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10792>
_______________________________________

From report at bugs.python.org  Wed Dec 29 21:07:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Dec 2010 20:07:09 +0000
Subject: [issue10792] Compile() and 'Windows/Mac newlines'
In-Reply-To: <1293652902.05.0.92926379276.issue10792@psf.upfronthosting.co.za>
Message-ID: <1293653229.94.0.892715696396.issue10792@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I made a mistake in testing. Sorry for the noise.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10792>
_______________________________________

From report at bugs.python.org  Wed Dec 29 21:36:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Dec 2010 20:36:28 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTikiPRx62szpf3H6VnQ3ZqA++3fv9CH9h2HKVZu+@mail.gmail.com>
Message-ID: <1293655042.18690.20.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 29 d?cembre 2010 ? 19:26 +0000, Alexander Belopolsky a
?crit :
> Would it look as exotic if presented like this?
> 
>   File "<stdin>", line 1
>     ? = 5
>        ^
> SyntaxError: invalid character in identifier
> (works on a wide build)

Use non-ASCII identifiers is exotic. Use non-BMP identifiers is
crazy :-) Seriously, it can wait 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Dec 29 22:59:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 21:59:16 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293659956.73.0.547642256203.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since GZipFile inherits from BufferedIOBase, and TextIOWrapper is supposed to be designed to wrap a BufferedIOBase object, I would say yes it ought to work.  On the other hand there may also be a doc error there, since it may be that TextIOWrapper actually needs to wrap one of the subclasses of BufferedIOBase.

----------
nosy: +pitrou, r.david.murray
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:00:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 22:00:19 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293660019.49.0.893691059837.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oops.  It only has that inheritance in 3.2.

----------
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:01:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 22:01:40 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293660100.76.0.75969240598.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Heh, and 2.7.  Fixing versions yet again.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:12:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Dec 2010 22:12:11 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293660731.6.0.787990909361.issue10791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should be easy to fix, if only the "readable" and "writable" methods are needed. Do you want to try writing a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:49:33 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 29 Dec 2010 22:49:33 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293662973.74.0.67364830326.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

It goes without saying that this also needs to be checked with the bz2 module. A quick check seems to indicate that it has the same problem.

While you're at it, maybe someone could add an 'open' function to bz2 to make it symmetrical with gzip as well :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:55:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 22:55:01 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293663301.56.0.159438802776.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

bz2 is a pure C module, so that's a very different situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:56:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Dec 2010 22:56:36 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293662973.74.0.67364830326.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293663390.3709.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> While you're at it, maybe someone could add an 'open' function to bz2
> to make it symmetrical with gzip as well :-).

That's a nice idea, but quite orthogonal to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Dec 29 23:58:12 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 29 Dec 2010 22:58:12 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293663492.51.0.742969104086.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

C or not, wrapping a BZ2File instance with a TextIOWrapper to get text still seems like something that someone might want to do.  I doubt it would take much modification to give BZ2File instances the required set of methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:04:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 23:04:57 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1293655042.18690.20.camel@marge>
Message-ID: <AANLkTim5kNbMFvWP4Rq56ifPvHmsonezEA9fZpmHOBwY@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 29, 2010 at 3:36 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> Use non-ASCII identifiers is exotic. Use non-BMP identifiers is
> crazy :-)

Hmm, we clearly disagree on what crosses the boundary of the mental
norm.   IMHO, it is crazy to require users to care which plane their
characters come from or whether their programs will be run on a wide
or a narrow build.  I see nothing wrong with a desire to use
characters from say "Mathematical Alphanumeric Symbols" block if that
makes some Python expressions look more like the mathematical formulas
that they represent.  However, it is not about any particular usage,
but about the language definition.  I don't remember even a suggestion
during PEP 3131 discussion that non-BMP characters should be excluded
from identifiers wholesale.

In any case, can someone remind me what was the use case that
motivated chr(i) returning a two-character string for i > 0xFFFF?  I
think we should either stop pretending that narrow builds can handle
non-BMP characters and disallow them in Python strings or we should
try to fix the bugs associated with them.

> Seriously, it can wait 3.3.

What exactly can wait until 3.3?  The presented patch introduces no
user visible changes.  It is only a stepping stone to restoring some
sanity in a way supplementary characters are treated by narrow builds.
 At the moment, it is a mine field: you can easily produce surrogate
pairs from string literals and codecs, but when you start using them,
you have 50% chance that things will blow up, 40% chance of getting
wrong result and maybe 10% chance that it will work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:05:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 23:05:20 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293663920.9.0.000405545562973.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Right, but in the bz2 case I think it is a feature request rather than a bugfix.  In any case it should be a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:10:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Dec 2010 23:10:51 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293663492.51.0.742969104086.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293664246.3709.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> C or not, wrapping a BZ2File instance with a TextIOWrapper to get text
> still seems like something that someone might want to do.  I doubt it
> would take much modification to give BZ2File instances the required
> set of methods.

BZ2File uses FILE pointers internally so it may be more complicated than
it looks to be (because the methods may not have the right semantics).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:12:19 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 29 Dec 2010 23:12:19 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293664339.24.0.49698937532.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Do Python devs really view gzip and bz2 as two totally completely different animals?  They both have the same functionality and would be used for the same kinds of things.   Maybe I'm missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:14:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Dec 2010 23:14:23 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293664339.24.0.49698937532.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293664459.3709.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Do Python devs really view gzip and bz2 as two totally completely
> different animals?  They both have the same functionality and would be
> used for the same kinds of things.   Maybe I'm missing something.

Well, the reality of divergent implementation strategies trumps the
theory of API compatibility :) The approach taken by bz2 is IMO
regrettable, but it's not a ten minutes job to write it again from
scratch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:17:39 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 29 Dec 2010 23:17:39 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1293664659.74.0.611322216831.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Hmmm. Interesting.  In the big picture, it might be an interesting project for someone (not necessarily the core devs) to sit down and refactor both of these modules so that they play nice with Python 3 I/O system.  Obviously that's a project outside the scope of this bug or the 3.2 release for that matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:31:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 23:31:38 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1293665498.23.0.336989842043.issue8271@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/issue8271>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:56:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Dec 2010 23:56:10 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1293666970.58.0.699185815671.issue1674555@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One way to "fix" this would be to have make test run the tests with -j1 and pass in the -S and -s flags, and then have regrtest special case test_site and remove those flags for the run of that single test.

An interesting facet of this proposal in that it actually isolates the tests better.  But it will also slow down the test suite run a bit.  Since the tests are already run twice by make test, that may not matter all that much (that is, it's a start-the-run-and-walk-away situation anyway).

Note that all tests except test_trace currently pass with -S -s.

----------
stage: unit test needed -> needs patch
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Thu Dec 30 00:59:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Dec 2010 23:59:22 +0000
Subject: [issue8821] Range check on unicode repr
In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>
Message-ID: <1293667162.36.0.732596443066.issue8821@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

[MAL]
>  * Unicode objects are NUL-terminated, but only very external APIs
>    rely on this (e.g. code using the Windows Unicode API). Please
>    don't make the code in unicodeobject.c itself rely on this
>    subtle detail.

I would like to note that several APIs have been introduced that require NUL-terminated unicode strings: Py_UNICODE_strlen(), Py_UNICODE_strcpy(), etc.  I see them used quite extensively in unicodeobject.c and elsewhere in Python codebase. Perhaps this train has left the station already.

----------
nosy: +belopolsky, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8821>
_______________________________________

From report at bugs.python.org  Thu Dec 30 01:06:59 2010
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 30 Dec 2010 00:06:59 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293667619.18.0.388569666942.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

More an observation than a bug:

I understand that we're trading memory for performance, but I've noticed that the peak memory usage is rather high, e.g.:

$ cat test.py
import os
import regex as re

def resident():
    for line in open('/proc/%d/status' % os.getpid(), 'r').readlines():
        if line.startswith("VmRSS:"):
            return line.split(":")[-1].strip()

cache = {}

print resident()
for i in xrange(0,1000):
    cache[i] = re.compile(str(i)+"(abcd12kl|efghlajsdf|ijkllakjsdf|mnoplasjdf|qrstljasd|sdajdwxyzlasjdf|kajsdfjkasdjkf|kasdflkasjdflkajsd|klasdfljasdf)")

print resident()


Execution output on my machine (Linux x86_64, Python 2.6.5):
4328 kB
32052 kB

with the standard regex library:
3688 kB
5428 kB

So, it looks like around 16x the memory per pattern vs standard regex module

Now the example is pretty silly, the difference is even larger for more complex regexes.  I also understand that the once the patterns are GC-ed, python can reuse the memory (pymalloc doesn't return it to the OS, unfortunately).  However, I have some applications that use large numbers (many thousands) of regexes and need to keep them cached (compiled) indefinitely (especially because compilation is expensive).  This causes some pain (long story).

I've played around with increasing RE_MIN_FAST_LENGTH, and it makes a significant difference, e.g.:

RE_MIN_FAST_LENGTH = 10:
4324 kB
25976 kB

In my use-cases, having a larger RE_MIN_FAST_LENGTH doesn't make a huge performance difference, so that might be the way I'll go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 01:24:32 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Thu, 30 Dec 2010 00:24:32 +0000
Subject: [issue10793] hashlib.hash.digest() documentation incorrect re return
	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>


New submission from Thorsten Behrens <sbehrens at gmx.li>:

The documentation for hashlib.hash.digest() states that digest() will "[r]eturn the digest of the data passed to the update() method so far. This is a bytes array of size digest_size[...]".

The returned object is of class 'bytes', not 'bytearray'. Documentation should reflect this.

----------
assignee: docs at python
components: Documentation
messages: 124892
nosy: docs at python, thorsten.behrens
priority: normal
severity: normal
status: open
title: hashlib.hash.digest() documentation incorrect re return type
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10793>
_______________________________________

From report at bugs.python.org  Thu Dec 30 01:41:35 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 30 Dec 2010 00:41:35 +0000
Subject: [issue10793] hashlib.hash.digest() documentation incorrect re return
	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293669695.57.0.594332558513.issue10793@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

One-word patch attached.

----------
keywords: +patch
nosy: +SilentGhost
Added file: http://bugs.python.org/file20191/hashlib.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10793>
_______________________________________

From report at bugs.python.org  Thu Dec 30 01:45:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Dec 2010 00:45:28 +0000
Subject: [issue8821] Range check on unicode repr
In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>
Message-ID: <1293669928.94.0.203002875235.issue8821@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Unicode objects are NUL-terminated, but only very external APIs
> rely on this (e.g. code using the Windows Unicode API).

All Py_UNICODE_str*() functions rely on the NUL character. They are useful when patching a function from bytes (char*) to unicode (PyUnicodeObject): the API is very close. It is possible to avoid them with new functions using the strings length.

All functions using PyUNICODE* as wchar_t* to the Windows wide character API (*W functions) also rely on the NUL character. Python core uses a lot of these functions. Don't write a NUL character require to create a temporary new string ending with a NUL character. It is not efficient, especially on long strings.

And there is the problem of all third party modules (written in C) relying on the NUL character.

I think that we have good reasons to not remove the NUL character. So I think that we can continue to accept that unicode[length] character can be read. Eg. implement text.startswith("ab") as "p=PyUnicode_AS_UNICODE(text); if (p[0] == 'a' && p[1] == 'b')" without checking the length of text.

Using the NUL character or the length as a terminator condition doesn't really matter. I just see one advantage for the NUL character: it is faster in some cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8821>
_______________________________________

From report at bugs.python.org  Thu Dec 30 01:48:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 30 Dec 2010 00:48:11 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1293670091.32.0.0858293111214.issue3232@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Martin's original code (r32301) was pretty clear:

 32301     loewis         # IDNA allows decoding to operate on Unicode strings, too.
 32301     loewis         if isinstance(input, unicode):
 32301     loewis             labels = dots.split(input)
 32301     loewis         else:
 32301     loewis             # Must be ASCII string
 32301     loewis             unicode(input, "ascii")
 32301     loewis             labels = input.split(".")

but the py3k port, r55215, was clearly incomplete and the log message is explicit about it:


r55215 | guido.van.rossum | 2007-05-09 19:40:37 -0400 (Wed, 09 May 2007) | 3 lines

Random modifications that slightly improve the chances of this not blowing up.
Walter will fix it for real.

I hope I picked the right Walter for the "nosy" list.

----------
nosy: +belopolsky, doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Thu Dec 30 01:51:27 2010
From: report at bugs.python.org (Mihai Rusu)
Date: Thu, 30 Dec 2010 00:51:27 +0000
Subject: [issue10794] Infinite recursion while garbage collecting loops
	indefinitely
In-Reply-To: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>
Message-ID: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>


New submission from Mihai Rusu <dizzy at google.com>:

Hi

While working on some Python code I stumbled on a situation where the Python process seems to hang indefinitely. Further debugging points to the following conclusion: if there is a class that somehow manages to run into an infinite recursion (properly detected by Python which raises the corresponding RuntimeError) while Python is doing garbage collection (so the infinite recursion has to be triggered from __del__ somehow) then Python hangs into an infinite loop apparently retrying to call that __del__ indefinitely. The described behavior happens ONLY when an infinite recursion is detected (ie if I raise my own "RuntimeError" from __del__ then it just logs it and exits).

Program showing the problem:

class A(object):
  def __init__(self):
    raise Exception('init error')
    self.m = 'Hello world'

  def __del__(self):
    #raise RuntimeError('my runtime error')
    self.__del__()

def func():
  h = A()

func()

$ python pyloop.py

Traceback (most recent call last):
  File "pyloop.py", line 15, in <module>
    func()
  File "pyloop.py", line 13, in func
    h = A()
  File "pyloop.py", line 5, in __init__
    raise Exception('init error')
Exception: init error
Exception RuntimeError: 'maximum recursion depth exceeded' in <bound method A.__del__ of <__main__.A object at 0x17bb7d0>> ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in <bound method A.__del__ of <__main__.A object at 0x17bb7d0>> ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in <bound method A.__del__ of <__main__.A object at 0x17bb7d0>> ignored
Exception RuntimeError: 'maximum recursion depth exceeded' in <bound method A.__del__ of <__main__.A object at 0x17bb7d0>> ignored
...

If I uncomment the line raising my RuntimeError instance from __del__ then the exception is logged once and the program exits (as expected).

Please help, thanks.

----------
components: Interpreter Core
messages: 124896
nosy: Mihai.Rusu, gregory.p.smith
priority: normal
severity: normal
status: open
title: Infinite recursion while garbage collecting loops indefinitely
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10794>
_______________________________________

From report at bugs.python.org  Thu Dec 30 02:02:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Dec 2010 01:02:46 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTim5kNbMFvWP4Rq56ifPvHmsonezEA9fZpmHOBwY@mail.gmail.com>
Message-ID: <4D1BDA31.7090305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Seriously, it can wait 3.3.
> 
> What exactly can wait until 3.3?  The presented patch introduces no
> user visible changes.  It is only a stepping stone to restoring some
> sanity in a way supplementary characters are treated by narrow builds.
>  At the moment, it is a mine field: you can easily produce surrogate
> pairs from string literals and codecs, but when you start using them,
> you have 50% chance that things will blow up, 40% chance of getting
> wrong result and maybe 10% chance that it will work.

I think the proposal is that fixing this minefield can wait until
Python 3.3 (or even 3.4, or later).

I plan to propose a complete redesign of the representation of Unicode
strings, which may well make this entire set of changes obsolete.

As for language definition: I think the definition is quite clear
and unambiguous. It may be that Python 3.2 doesn't fully implement it.

IOW: relax.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 02:42:40 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Thu, 30 Dec 2010 01:42:40 +0000
Subject: [issue10795] standard library do not use ssl as recommended
In-Reply-To: <1293673360.75.0.570895204435.issue10795@psf.upfronthosting.co.za>
Message-ID: <1293673360.75.0.570895204435.issue10795@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

As discussed on issue1589 it is now possible to create decent ssl connections with the ssl module - assuming ca_certs is specified and it is checked that the certificates matches.

The standard library do however neither do that nor make it possible to do it in the places where it uses ssl. For example smtplib starttls do not make it possible at all to specify ca_certs.

I suggest all uses of ssl should be reviewed - and fixed if necessary. The documentation should also be improved to make it clear what is necessary to create "secure" connections.

----------
components: Library (Lib)
messages: 124898
nosy: kiilerix, pitrou
priority: normal
severity: normal
status: open
title: standard library do not use ssl as recommended
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10795>
_______________________________________

From report at bugs.python.org  Thu Dec 30 02:53:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 30 Dec 2010 01:53:48 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1293674028.79.0.123954272036.issue3232@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Arguably, it is not a bug if codec's decode method rejects unicode strings with a TypeError.  The 2.x implementation seems to allow decoding of ASCII-only unicode labels joined by arbitrary RFC 3490 separators.  I am not sure what the use case for this behavior would be.  In any case, supporting this would be a feature and it's acceptance would depend on the outcome of #7475.

----------
dependencies: +codecs missing: base64 bz2 hex zlib hex_codec ...
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Thu Dec 30 03:25:58 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 30 Dec 2010 02:25:58 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293675958.76.0.707778280457.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101230.zip is a new version of the regex module.

I've delayed the building of the tables for fast searching until their first use, which, hopefully, will mean that fewer will be actually built.

----------
Added file: http://bugs.python.org/file20192/issue2636-20101230.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 03:37:22 2010
From: report at bugs.python.org (Matt Giuca)
Date: Thu, 30 Dec 2010 02:37:22 +0000
Subject: [issue8821] Range check on unicode repr
In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>
Message-ID: <1293676642.4.0.746877108447.issue8821@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

> I think that we have good reasons to not remove the NUL character.

Please note: Nobody is suggesting that we remove the NUL character. I was merely suggesting that we don't rely on it where it is unnecessary.

Returning to my original patch: If the code was using the NUL character as a terminator, then it wouldn't be a bug.

What the repr code does is it uses the length, and does not explicitly search for a NUL character. However, there is a *bug* where it reads one too many characters in certain cases. As I said in the first place, it just happens to *not* be catastrophic due to the presence of the NUL character. But that does not mean this isn't a bug -- at the very least, the code is very confusing to read because it does not do what it is trying to do.

Anyway the important issue is what Marc-Andre raised about buffers. Since we are in agreement that there is a potential problem here, and I have a patch which seems correct and doesn't break any test cases (note my above post responding to test case breakages), can it be applied?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8821>
_______________________________________

From report at bugs.python.org  Thu Dec 30 03:38:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 30 Dec 2010 02:38:41 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <4D1BDA31.7090305@v.loewis.de>
Message-ID: <AANLkTi=52uek6ByQSZ9E3aChYiQ15TukrDLKw9Mrcec3@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 29, 2010 at 8:02 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
>
> I plan to propose a complete redesign of the representation of Unicode
> strings, which may well make this entire set of changes obsolete.
>

Are you serious?  This sounds like a py4k idea.  Can you give us a
hint on what the new representation will be?  Meanwhile, what it your
recommendation for application developers?  Should they attempt to fix
the code that assumes len(chr(i)) == 1?  Should text processing
applications designed to run on a narrow build simply reject non-BMP
text? Should application writers avoid using str.isxyz() methods?

> As for language definition: I think the definition is quite clear
> and unambiguous. It may be that Python 3.2 doesn't fully implement it.
>

Given that until recently (r87433) the PEP and the reference manual
disagreed on the definition, I have to ask what definition you refer
to.  What Python 3.2 (or rather 3.1) implements, however is important
because it has been declared to be *the* definition of the Python
language regardless of what PEPs docs have to say.

> IOW: relax.

This is the easy part. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 03:50:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 30 Dec 2010 02:50:42 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTi=52uek6ByQSZ9E3aChYiQ15TukrDLKw9Mrcec3@mail.gmail.com>
Message-ID: <AANLkTi==_UbPsAHGpcJVWokv+NhaBFkk54xmeyiRyE7b@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Dec 29, 2010 at 9:38 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Given that until recently (r87433) the PEP and the reference manual
> disagreed on the definition,

Actually, it looks like PEP 3131 and the Language Reference [1] still
disagree.  The latter says:

identifier  ::=  id_start id_continue*

which should probably be

identifier  ::=  xid_start xid_continue*

instead.
[1] http://docs.python.org/py3k/reference/lexical_analysis.html#identifiers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 05:09:00 2010
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 30 Dec 2010 04:09:00 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293682140.17.0.375259939634.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

Yeah, issue2636-20101230.zip DOES reduce memory usage significantly (30-50%) in my use cases;  however, it also tanks performance overall by 35% for me, so I'll prefer to stick with issue2636-20101229.zip (or some variant of it).

Maybe a regex compile-time option, although that's not necessary.

Thanks for the effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 05:49:52 2010
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 30 Dec 2010 04:49:52 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293684592.55.0.308008598698.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

re.search('\d{4}(\s*\w)?\W*((?!\d)\w){2}', "9999XX")

matches on stock 2.6.5 regex module, but not on issue2636-20101230.zip or issue2636-20101229.zip (which I've fallen back to for now)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 06:24:31 2010
From: report at bugs.python.org (Jacques Grove)
Date: Thu, 30 Dec 2010 05:24:31 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293686671.79.0.925021298803.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

Another one that diverges between stock regex and issue2636-20101229.zip:

re.search('A\s*?.*?(\n+.*?\s*?){0,2}\(X', 'A\n1\nS\n1 (X')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 07:46:35 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 30 Dec 2010 06:46:35 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1293479986.26.0.682359680328.issue9893@psf.upfronthosting.co.za>
Message-ID: <20101230064620.GA3288@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Mon, Dec 27, 2010 at 07:59:46PM +0000, Brett Cannon wrote:

> But if you have a local copy of the Vim files from the community
> what is preventing you from editing them for new keywords and
> sending a patch to the maintainer so that the rest of the community
> is brought up to speed that much faster?

You mean the Python Core Dev maintaining a set of Vim files as a fork
from the vim.org maintained files and adding new features when they
come up and be submitted the vim.org.

If that is the idea, it is indeed a good one.

But often it has happened that someone at the vim.org has noticed the
changes in Python and updated the files and the scripts at vim.org
remain updated.

> I suspect that not many people beyond core devs use the Misc/Vim
> file while more people in the community use the vim.org files.

Possibly and perhaps that is reason to discard our Misc/Vim in favor
of vim.org files.

But if you think there *should* be an official recommendation, some
pointers would definitely serve.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Thu Dec 30 08:21:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 30 Dec 2010 07:21:34 +0000
Subject: [issue10793] hashlib.hash.digest() documentation incorrect re return
	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293693694.94.0.389116739413.issue10793@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r87573 and r87574

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10793>
_______________________________________

From report at bugs.python.org  Thu Dec 30 08:41:26 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 30 Dec 2010 07:41:26 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293694886.02.0.679254696729.issue2636@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

As belopolsky said... *please* move this development into version control.  Put it up in an Hg repo on code.google.com.  or put it on github.  *anything* other than repeatedly posting entire zip file source code drops to a bugtracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 08:57:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Dec 2010 07:57:47 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTi=52uek6ByQSZ9E3aChYiQ15TukrDLKw9Mrcec3@mail.gmail.com>
Message-ID: <4D1C3B78.8070809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Are you serious?  This sounds like a py4k idea.  Can you give us a
> hint on what the new representation will be?

I'm thinking about an approach of a variable representation:
one, two, or four bytes, depending on the widest character that
appears in the string. I think it can be arranged to make this mostly
backwards-compatible with existing APIs, so it doesn't need to wait
for py4k, IMO. OTOH, I'm not sure I'll make it for 3.3.

> Meanwhile, what it your
> recommendation for application developers?  Should they attempt to fix
> the code that assumes len(chr(i)) == 1?  Should text processing
> applications designed to run on a narrow build simply reject non-BMP
> text? Should application writers avoid using str.isxyz() methods?

Given that this is vaporware: proceed as if that idea didn't exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 09:38:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Dec 2010 08:38:22 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTi==_UbPsAHGpcJVWokv+NhaBFkk54xmeyiRyE7b@mail.gmail.com>
Message-ID: <4D1C44FA.6050904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Actually, it looks like PEP 3131 and the Language Reference [1] still
> disagree.  The latter says:
> 
> identifier  ::=  id_start id_continue*
> 
> which should probably be
> 
> identifier  ::=  xid_start xid_continue*
> 
> instead.

Interesting. XID_* is being used in the PEP since r57023, whereas the
documentation was added in r57824. In any case, this is now fixed in
r87575/r87576.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 09:45:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 08:45:37 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293698737.2.0.908387223332.issue2636@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hearty +1.  I have the hope of putting this in 3.3, and for that I'd like to see how the code matures, which is much easier when in version control.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 11:55:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Dec 2010 10:55:15 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1293706515.66.0.119286949304.issue3232@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Arguably, it is not a bug if codec's decode method rejects unicode
> strings with a TypeError.

Agreed, but it would be better if it did so deliberately and explicitly, rather than as a result of a bogus forward-port ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Thu Dec 30 12:14:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 11:14:53 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1293707693.19.0.833293133625.issue10542@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> I think the proposal is that fixing this minefield can wait until
> Python 3.3 (or even 3.4, or later).

That is what I was thinking.  (Alex: You might not know that Martin
was the main proponent of non-ASCII identifiers, so this assessment
should have some weight.)

> I'm thinking about an approach of a variable representation:
> one, two, or four bytes, depending on the widest character that
> appears in the string. I think it can be arranged to make this mostly
> backwards-compatible with existing APIs, so it doesn't need to wait
> for py4k, IMO. OTOH, I'm not sure I'll make it for 3.3.

That is an interesting idea.  I would be interested in helping out
when you'll implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Dec 30 13:27:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Dec 2010 12:27:27 +0000
Subject: [issue10794] Infinite recursion while garbage collecting loops
	indefinitely
In-Reply-To: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>
Message-ID: <1293712047.23.0.81806011221.issue10794@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Normally you should never call __del__, OTOH the issue is the same with a class like::

class A:
    def close(self):
        self.close()
    def __del__(self):
        self.close()

The problem is not with _infinite_ recursion, though; a depth of 47 is enough (but 46 won't show the problem)::

class A:
    def __del__(self):
        self.recurse(47)
    def recurse(self, n):
        if n:
            self.recurse(n-1)
        else:
            raise ValueError

Hint: PyTrash_UNWIND_LEVEL is defined to 50; I checked that recompiling Python with a different value also changes the necessary recursion depth.

There is some nasty interaction between the "Trashcan mechanism" and resurrected objects stored in deep structures. A list is enough, no need to involve frames and exceptions::

class C:
    def __del__(self):
        print ".",
        x = self
        for i in range(49):    # PyTrash_UNWIND_LEVEL-1
            x = [x]
l = [C()]
del l

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10794>
_______________________________________

From report at bugs.python.org  Thu Dec 30 13:30:36 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Dec 2010 12:30:36 +0000
Subject: [issue10794] Infinite recursion while garbage collecting loops
	indefinitely
In-Reply-To: <1293670287.34.0.585233901325.issue10794@psf.upfronthosting.co.za>
Message-ID: <1293712236.99.0.411729637999.issue10794@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Precision: with new-styles classes (or py3k) the limit is PyTrash_UNWIND_LEVEL-2. This does not change anything to the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10794>
_______________________________________

From report at bugs.python.org  Thu Dec 30 14:08:09 2010
From: report at bugs.python.org (rheise)
Date: Thu, 30 Dec 2010 13:08:09 +0000
Subject: [issue10796] readline completion flaw
In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>
Message-ID: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>


New submission from rheise <ralfheise at freenet.de>:

Python's readline library generates out of the choices provided by a custom completion function the wrong terminal input. Say, the completion function suggests 'foobar' and 'foobaz' as matching completion strings, readline should produce the characters 'fooba' to prompt and await further interaction by the user. 
This is the intended behaviour of readline and this works in Python as well. However this does nod work anymore as soon, as the suggestion 
list contains dashes `-' as input argument. 

A working as supposed example:

>>> import readline
>>> 
>>> def complete(text, state):
...   if (state == 0):
...     return "abc"
...   if (state == 1):
...     return "ade"
...   else:
...     return None
... 
>>> 
>>> readline.parse_and_bind("Tab: complete")
>>> readline.set_completer(complete)
>>> 
>>> raw_input()
a
abc  ade  
a
'a'
>>> 

remark: I entered a and hit tab. readline produces abc/ade as valid choices, stopping at the first ambiguous character. Now consider the following example:

>>> import readline
>>> 
>>> def complete(text, state):
...   if (state == 0):
...     return "a-bc"
...   if (state == 1):
...     return "a-de"
...   else:
...     return None
... 
>>> 
>>> readline.parse_and_bind("Tab: complete")
>>> readline.set_completer(complete)
>>> 
>>> raw_input()
a-a-a-
'a-a-a-'
>>> 

The intended behaviour is the very same as for the first example. Readline should produce 'a-' and offer a-bc and a-de as valid choices. Instead it produces an additional a- for every time I hit tab. 

Same for Python3.1:

$ python3.1
Python 3.1.2 (release31-maint, Sep 26 2010, 13:51:01) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> 
>>> def complete(text, state):
...   if (state == 0):
...     return "a-bc"
...   if (state == 1):
...     return "a-de"
...   else:
...     return None
... 
>>> 
>>> readline.parse_and_bind("Tab: complete")
>>> readline.set_completer(complete)
>>> 
>>> input()
a-a-a-a-a-
'a-a-a-a-a-'
>>> 


Other programming languages falling back to the GNU C-readline library don't have this problem. Consider the roughly equivalent example in Perl which works as expected:

use Term::ReadLine;

sub complete
{
        my ($text, $state) = @_;
        if ($state == 0)
        {
                return "a-bc";
        }
        elsif ($state == 1)
        {
                return "a-cd";
        }
        else
        {
                return undef;
        }
}

my $term = new Term::ReadLine 'sample';
my $attribs = $term->Attribs;

$term->parse_and_bind("Tab: complete");
$attribs->{completion_entry_function} = \&complete;

$term->readline();



Running it:

$ perl rl 
a-
a-bc  a-cd  
a-

----------
components: Library (Lib)
messages: 124917
nosy: rheise
priority: normal
severity: normal
status: open
title: readline completion flaw
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10796>
_______________________________________

From report at bugs.python.org  Thu Dec 30 14:30:04 2010
From: report at bugs.python.org (Patrick W.)
Date: Thu, 30 Dec 2010 13:30:04 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293715804.49.0.624962778611.issue6210@psf.upfronthosting.co.za>


Patrick W. <poke at BornToLaugh.de> added the comment:

Nick Coghlan (ncoghlan) at 2010-12-29 08:46 (UTC):
> No, the context must always be included unless explicitly suppressed.

Then there should be some actually working way to suppress it, right?

I think the standard behaviour that automatically sets the `__context__` of an exception is fine, especially when thinking about exceptions that get raised inside `except` blocks and are not custom made. However there should be some way to suppress the context in some way.

Personally, I would prefer if `raise .. from ..` would set the exception's cause, but would *not* automatically print that cause. But then again, it would be a problem to get the cause afterwards when the program terminated because of that exception. So obviously, in such situations, both the cause and the context of a raised exception cannot be used (because both prints out the full trackback).

So we obviously need some new mechanism or syntax to ignore the previous exception. As it seems that the cause has a higher precedence than the context (which is fine as the cause is changeable), using `None` as the cause of an exception would be the best solution in my opinion:

    try:
        x / y
    except ZeroDivisionError as e:
        raise Exception( 'Invalid value for y' ) from None

While it might be difficult as the cause is `None` before and gets set to `None` afterwards, Python is totally able to detect that the value was explicitely set to `None`. Either the raise statement should set some internal flag, or the setter for `__cause__` should just check when it is first written to.

If that would be too complicated (although it would be possible and very logically to do it like that), maybe a different syntax would work:

    try:
        x / y
    except ZeroDivisionError as e:
        raise Exception( 'Invalid value for y' ) instead

Something like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Thu Dec 30 14:42:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Dec 2010 13:42:26 +0000
Subject: [issue10795] standard library do not use ssl as recommended
In-Reply-To: <1293673360.75.0.570895204435.issue10795@psf.upfronthosting.co.za>
Message-ID: <1293716546.58.0.915112332279.issue10795@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are open issues for specific modules: #8808 for imaplib, #8809 for smtplib.
In 3.2, poplib already has support for SSL contexts, as do ftplib, http.client and nntplib. If I'm missing a module please tell me.

----------
resolution:  -> duplicate
status: open -> closed
type:  -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10795>
_______________________________________

From report at bugs.python.org  Thu Dec 30 18:15:44 2010
From: report at bugs.python.org (Mark Roddy)
Date: Thu, 30 Dec 2010 17:15:44 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293729344.95.0.74595187914.issue10786@psf.upfronthosting.co.za>


Changes by Mark Roddy <markroddy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20193/py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Thu Dec 30 18:16:10 2010
From: report at bugs.python.org (Mark Roddy)
Date: Thu, 30 Dec 2010 17:16:10 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293729370.33.0.469085546517.issue10786@psf.upfronthosting.co.za>


Changes by Mark Roddy <markroddy at gmail.com>:


Added file: http://bugs.python.org/file20194/py32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Thu Dec 30 18:18:35 2010
From: report at bugs.python.org (Mark Roddy)
Date: Thu, 30 Dec 2010 17:18:35 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293729515.18.0.694263202193.issue10786@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

All patches change the default value of stream to None in the constructor, and set it to the current to sys.stderr if the argument is None.  Unit tests included to check this behavior.  

Also, the patch against Python 3.1 adds the Test_TextTestRunner test case to the list of tests to be run.  Apparently this test case was not being run.

----------
nosy: +MarkRoddy
Added file: http://bugs.python.org/file20195/py31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Thu Dec 30 18:31:43 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 30 Dec 2010 17:31:43 +0000
Subject: [issue10794] Infinite recursion while garbage collecting loops
	indefinitely
In-Reply-To: <1293712236.99.0.411729637999.issue10794@psf.upfronthosting.co.za>
Message-ID: <AANLkTikN_3D24jExr7PECfR0yUEzL6XgXyQoU1sEWqr_@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

FWIW, the example pasted in the bug was the smallest one he could come up
with.  in reality we were never calling .__del__() explicitly. We ran into
the problem due to a __del__ method triggering a __getattr__ call and the
__getattr__ ending up in infinite recursion because an attribute it accessed
internally wasn't defined.  That particular bug was fixable by fixing the
__getattr__ to not depend on any instance attributes but it is still a
problem in Python for the interpreter to get into an infinite loop calling
the destructor in that case...

----------
Added file: http://bugs.python.org/file20196/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10794>
_______________________________________
-------------- next part --------------
FWIW, the example pasted in the bug was the smallest one he could come up with. ??in reality we were never calling .__del__() explicitly.??We ran into the problem due to a __del__ method triggering a __getattr__ call and the __getattr__ ending up in infinite recursion because an attribute it accessed internally wasn&#39;t defined. ??That particular bug was fixable by fixing the __getattr__ to not depend on any instance attributes but it is still a problem in Python for the interpreter to get into an infinite loop calling the destructor in that case...<div>

<br></div><div><br></div>

From report at bugs.python.org  Thu Dec 30 18:40:39 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 30 Dec 2010 17:40:39 +0000
Subject: [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1293730839.12.0.811998888225.issue10681@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

For reference, this seems to affect SWIG, specifically, I'm seeing build failures using:
  /usr/share/swig/2.0.1/python/pycontainer.swg
from swig-2.0.1

See downstream build failure report for znc, which uses swig to generate python 3 bindings:
  https://bugzilla.redhat.com/show_bug.cgi?id=666429

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10681>
_______________________________________

From report at bugs.python.org  Thu Dec 30 18:46:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 30 Dec 2010 17:46:18 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1293731178.25.0.300088294296.issue6632@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wonder if the issues raised here can be neatly addressed by applying NFKC normalization before string to number conversion.  This will convert full-width variants to ASCII and also eliminate digit/decimal differences.  For example superscript and subscript variants will be converted to ASCII.  Note that NFKC normalization is already applied to identifiers, so its effect should be familiar to users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Thu Dec 30 19:10:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Dec 2010 18:10:31 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1293732631.91.0.010705223057.issue9893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alright, let me change my opinion: Let?s replace the Vim files by a README.vim file explaining where to get good helper files (like Misc/README.emacs added in r85927).  Then I will learn how to manage my Vim configuration to keep it updated (and adequate for each Python version), and when needed contact the Vim community to request updates.

----------
stage:  -> needs patch
type: resource usage -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Thu Dec 30 19:11:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Dec 2010 18:11:59 +0000
Subject: [issue1816] sys.cmd_flags patch
In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za>
Message-ID: <1293732719.76.0.912441837086.issue1816@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve recently remarked that -i maps to both sys.flags.inspect and sys.flags.interactive.  Is this behavior useful?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1816>
_______________________________________

From report at bugs.python.org  Thu Dec 30 19:21:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Dec 2010 18:21:06 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293733266.51.0.690976652221.issue6210@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> using `None` as the cause of an exception would be the 
> best solution in my opinion:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Thu Dec 30 19:32:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Dec 2010 18:32:49 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293733266.51.0.690976652221.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293733961.14809.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > using `None` as the cause of an exception would be the 
> > best solution in my opinion:
> 
> +1

We are talking about context, not cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Thu Dec 30 19:37:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Dec 2010 18:37:08 +0000
Subject: [issue1284670] Allow to restrict ModuleFinder to get "direct"
	dependencies
Message-ID: <1293734228.83.0.838357866897.issue1284670@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The depth parameter idea sounds like YAGNI, so let?s stay with a recurse boolean :)

----------
assignee:  -> eric.araujo
nosy:  -BreamoreBoy, misc_from_metz
stage: unit test needed -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284670>
_______________________________________

From report at bugs.python.org  Thu Dec 30 20:13:42 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 30 Dec 2010 19:13:42 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293736422.89.0.0898746321472.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The project is now at:

    https://code.google.com/p/mrab-regex/

Unfortunately it doesn't have the revision history. I don't know why not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 20:37:49 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 30 Dec 2010 19:37:49 +0000
Subject: [issue10786] unittest.TextTextRunner does not respect redirected
	stderr
In-Reply-To: <1293519479.07.0.371916485658.issue10786@psf.upfronthosting.co.za>
Message-ID: <1293737869.8.0.012247055793.issue10786@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed to py3k in revision 87582.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10786>
_______________________________________

From report at bugs.python.org  Thu Dec 30 20:45:32 2010
From: report at bugs.python.org (Robert Xiao)
Date: Thu, 30 Dec 2010 19:45:32 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293738332.39.0.320939257968.issue2636@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

Do you have it in any kind of repository at all? Even a private SVN repo or something like that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 20:55:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Dec 2010 19:55:31 +0000
Subject: [issue10787] [random.gammavariate] Add the expression of the
	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293738931.45.0.16389340481.issue10787@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10787>
_______________________________________

From report at bugs.python.org  Thu Dec 30 21:09:34 2010
From: report at bugs.python.org (Miso.Kopera)
Date: Thu, 30 Dec 2010 20:09:34 +0000
Subject: [issue10797] Wrong detection of lines in readlines() function
In-Reply-To: <1293739774.28.0.868626171836.issue10797@psf.upfronthosting.co.za>
Message-ID: <1293739774.28.0.868626171836.issue10797@psf.upfronthosting.co.za>


New submission from Miso.Kopera <Miso.Kopera at gmail.com>:

bug in "file.readlines()" function. It doesn't detect end of the line when line is ending only with 0x0D byte. In python3.1 it works fine (as I expect). File in attachment should has 6 lines not only 1 as python2.7 returns.

----------
components: None
files: testFile
messages: 124932
nosy: Miso.Kopera
priority: normal
severity: normal
status: open
title: Wrong detection of lines in readlines() function
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20197/testFile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10797>
_______________________________________

From report at bugs.python.org  Thu Dec 30 21:14:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Dec 2010 20:14:14 +0000
Subject: [issue10798] test_concurrent_futures fails on FreeBSD
In-Reply-To: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>
Message-ID: <1293740054.42.0.931376139757.issue10798@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

This is similar to #10348, but has a different scope; the attached patch disables the ProcessPoolExecutor if the system has too few POSIX semaphores.

To keep support for the ThreadPoolExecutor, I had the test cases stop using multiprocessing.Event in the threaded test cases. Unfortunately, this had two side effect that I think indicate a bug elsewhere: 

1. ThreadPoolWaitTests.test_all_completed_some_already_completed hangs
2. (sometimes) ThreadPoolWaitTests.test_first_exception fails:

    self.assertEqual(set([future1, future2]), finished)
AssertionError: Items in the first set but not the second:
<Future at 0x1851ad0 state=running>

I haven't been able to determine yet why it hangs. If the hanging test is disabled, the tests pass on both Linux and FreeBSD 7.3.

----------
files: fbsd.diff
keywords: patch
messages: 124933
nosy: bquinlan, loewis
priority: normal
severity: normal
status: open
title: test_concurrent_futures fails on FreeBSD
Added file: http://bugs.python.org/file20198/fbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10798>
_______________________________________

From report at bugs.python.org  Thu Dec 30 21:22:22 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 30 Dec 2010 20:22:22 +0000
Subject: [issue10797] Wrong detection of lines in readlines() function
In-Reply-To: <1293739774.28.0.868626171836.issue10797@psf.upfronthosting.co.za>
Message-ID: <1293740542.45.0.345574276918.issue10797@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Either use mode 'U' or the io module if you want to match 3.x.

$ python
Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open('testFile').readlines()
['# blaaaaa\r#\r\t# blaaaaaaaa\r\t#\r\t#\r#blaaa\t\r']
>>> open('testFile', 'U').readlines()
['# blaaaaa\n', '#\n', '\t# blaaaaaaaa\n', '\t#\n', '\t#\n', '#blaaa\t\n']
>>> import io
>>> io.open('testFile').readlines()
[u'# blaaaaa\n', u'#\n', u'\t# blaaaaaaaa\n', u'\t#\n', u'\t#\n', u'#blaaa\t\n']

----------
nosy: +eric.smith
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10797>
_______________________________________

From report at bugs.python.org  Thu Dec 30 21:58:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 20:58:20 +0000
Subject: [issue1816] sys.cmd_flags patch
In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za>
Message-ID: <1293742700.96.0.836358767059.issue1816@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Maybe not, but note that there is both a Py_InteractiveFlag and Py_InspectFlag, and they enable different things (they are both set by -i, while setting the PYTHONINSPECT envvar only activates Py_InspectFlag).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1816>
_______________________________________

From report at bugs.python.org  Thu Dec 30 22:39:41 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 30 Dec 2010 21:39:41 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293745181.37.0.00319241026065.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

msg124904: It would, of course, be slower on first use, but I'm surprised that it's (that much) slower afterwards.

msg124905, msg124906: I have those matching now.

msg124931: The sources are in TortoiseBzr, but I couldn't upload, so I exported to TortoiseSVN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Dec 30 23:14:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 22:14:19 +0000
Subject: [issue7962] Demo and Tools need to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1293747259.05.0.496757805718.issue7962@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Removed Demo and some of the Tools in a series of commits starting with r87579.

----------
dependencies:  -Allow larger programs to be frozen under Win32, Demo/classes/Dates.py does not work in 3.x, Demo/embed/demo.c use of PySys_SetArgv() is invalid, Single-line option to pygettext.py, Tools/unicode/gencodec.py error, Use ISO timestamp in diff.py, add an optional "default" argument to tokenize.detect_encoding, replace dist/src/Tools/scripts/which.py with tmick's which, svnmerge errors in msgfmt.py, untabify.py fails on files that contain non-ascii characters
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Thu Dec 30 23:34:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 22:34:40 +0000
Subject: [issue3194] Demo/loop.c passing "char *" instead of "wchar_t *"
In-Reply-To: <1214364326.35.0.217778159942.issue3194@psf.upfronthosting.co.za>
Message-ID: <1293748480.62.0.493359508291.issue3194@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Demo/embed has now been removed.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3194>
_______________________________________

From report at bugs.python.org  Thu Dec 30 23:35:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 22:35:57 +0000
Subject: [issue10495] Demo/comparisons/sortingtest.py needs some usage
	information.
In-Reply-To: <1290386312.84.0.302753892173.issue10495@psf.upfronthosting.co.za>
Message-ID: <1293748557.72.0.763787167686.issue10495@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Demo/comparisons has now been removed.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10495>
_______________________________________

From report at bugs.python.org  Thu Dec 30 23:36:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 22:36:08 +0000
Subject: [issue10494] Demo/comparisons/regextest.py needs some usage
	information.
In-Reply-To: <1290384598.34.0.211944890611.issue10494@psf.upfronthosting.co.za>
Message-ID: <1293748568.46.0.489918684192.issue10494@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Demo/comparisons has now been removed.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10494>
_______________________________________

From report at bugs.python.org  Thu Dec 30 23:37:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 22:37:37 +0000
Subject: [issue9153] Run tests and demos as part of the test suite
In-Reply-To: <1278257563.58.0.0461591435659.issue9153@psf.upfronthosting.co.za>
Message-ID: <1293748657.85.0.764641678423.issue9153@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing; Demo/ is no more.

----------
nosy: +georg.brandl
resolution: accepted -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9153>
_______________________________________

From report at bugs.python.org  Thu Dec 30 23:40:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 30 Dec 2010 22:40:27 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1293748827.75.0.150537240761.issue2889@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Fri Dec 31 01:07:46 2010
From: report at bugs.python.org (Patrick W.)
Date: Fri, 31 Dec 2010 00:07:46 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1244228665.64.0.918101455838.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293754066.44.0.150961801844.issue6210@psf.upfronthosting.co.za>


Patrick W. <poke at BornToLaugh.de> added the comment:

Antoine Pitrou (pitrou) at 2010-12-30 18:32 (UTC)
> We are talking about context, not cause.

Yes, but - as said before - obviously the cause takes a higher precedence than context (otherwise it wouldn't show a context message when you explicitely set that). So when *explicitely* setting the cause to `None`, it should use the cause `None` and ignore the context, and as such display nothing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Fri Dec 31 02:09:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 01:09:08 +0000
Subject: [issue10537] OS X IDLE 2.7 from 64-bit installer hangs when you paste
	something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1293757748.1.0.4995961403.issue10537@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something. -> OS X IDLE 2.7 from 64-bit installer hangs when you paste something.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Fri Dec 31 02:27:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 01:27:00 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1293758820.02.0.158296745358.issue6864@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

According to Ronald (msg92914) and Ned (msg92923) this particular issue is 2.6 only (and fixed in 2.7 because of patches not backported).
2.6 is in security fix only mode.
So unless someone claims that this is a security issue (and Barry agrees) or reports that this particular issue appears in a current version (2.7.1, 3.1.3, 3.2) separate from other open Apple/Tk/IDLE issues, this should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Fri Dec 31 02:32:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 31 Dec 2010 01:32:48 +0000
Subject: [issue1816] sys.cmd_flags patch
In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za>
Message-ID: <1293759168.59.0.363617204338.issue1816@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, so having both flags makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1816>
_______________________________________

From report at bugs.python.org  Fri Dec 31 02:43:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 31 Dec 2010 01:43:04 +0000
Subject: [issue9771] add an optional "default" argument to
	tokenize.detect_encoding
In-Reply-To: <1283599930.65.0.476914851505.issue9771@psf.upfronthosting.co.za>
Message-ID: <1293759784.64.0.347099951966.issue9771@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9771>
_______________________________________

From report at bugs.python.org  Fri Dec 31 02:52:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 31 Dec 2010 01:52:40 +0000
Subject: [issue9153] Run tools and demos as part of the test suite
In-Reply-To: <1278257563.58.0.0461591435659.issue9153@psf.upfronthosting.co.za>
Message-ID: <1293760360.16.0.964379891213.issue9153@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems there is no easy way to test tools apart from human inspection.

----------
title: Run tests and demos as part of the test suite -> Run tools and demos as part of the test suite

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9153>
_______________________________________

From report at bugs.python.org  Fri Dec 31 03:09:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 02:09:39 +0000
Subject: [issue4685] IDLE will not open (2.6.1 on WinXP pro)
In-Reply-To: <1229543868.69.0.302225364257.issue4685@psf.upfronthosting.co.za>
Message-ID: <1293761379.59.0.161037891084.issue4685@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 is now security fix only.

----------
nosy: +terry.reedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4685>
_______________________________________

From report at bugs.python.org  Fri Dec 31 03:11:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 02:11:48 +0000
Subject: [issue2708] IDLE subprocess error
In-Reply-To: <1209391841.34.0.293801648559.issue2708@psf.upfronthosting.co.za>
Message-ID: <1293761508.16.0.151974061378.issue2708@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.0 is closed to fixed and 2.6 is security fix only.
This is otherwise a duplicate of similar issues.

----------
nosy: +terry.reedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2708>
_______________________________________

From report at bugs.python.org  Fri Dec 31 04:36:57 2010
From: report at bugs.python.org (s7v7nislands)
Date: Fri, 31 Dec 2010 03:36:57 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1293766617.9.0.546444093966.issue5315@psf.upfronthosting.co.za>


Changes by s7v7nislands <s7v7nislands at gmail.com>:


----------
nosy: +s7v7nislands

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5315>
_______________________________________

From report at bugs.python.org  Fri Dec 31 04:47:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 03:47:31 +0000
Subject: [issue10799] Improve webbrowser.open doc (and, someday, behavior?)
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

webbrowser.open (and two aliases):

1. document return value, which seems to be: True if a browser tab or window is opened, regardless of whether or not the url is found; False otherwise.

2. document that (on Windows, at least) the default browser only gets used if a non .htm(l) url starts with 'www' or 'http:'.

This is true because os.startfile(url) apparently only works if above is true, as required for the Start/Run box to recognize an entry as a url.

In particular, I have Firefox as default and 'www.google.com' and 'http://bugs.python.org' get opened in Firefox (new tab as requested). However, 'google.com' and 'bugs.python.org' open with IE after some delay. [Start/run either opens with Firefox or reports 'cannot find'.]
-----

In the longer run, what I would really like is for webbrowser to be better at using the default or finding executables.

I thought of adding 'http://' if not present but that would disable opening files in a file browser.

I suspect there is a registry entry but do not know what it is. That would also pick up new browswers like Chrome.

It seems to me that the current behavior is a 'limitation' in this code:

    # Detect some common Windows browsers, fallback to IE
    iexplore = os.path.join(os.environ.get("PROGRAMFILES", "C:\\Program Files"),
                            "Internet Explorer\\IEXPLORE.EXE")
    for browser in ("firefox", "firebird", "seamonkey", "mozilla",
                    "netscape", "opera", iexplore):
        if _iscommand(browser):
            register(browser, None, BackgroundBrowser(browser))

Firefox is not being recognized as a command because _iscommand('firefox') does not not see firefox.exe as an executable because it only checks _isexecutable() in the hodgepodge list of paths in PATH. At one time (but no longer), executables were ofter put in c:/windows, which by default is in PATH.

Since you hardcoded the default real path for iexplore (C:\\Program Files\\"Internet Explorer\\IEXPLORE.EXE"), you could do the same for other programs: 

firefox = os.path.join(os.environ.get("PROGRAMFILES", "C:\\Program Files"), "Mozilla Firefox\\firefox.exe")

----------
assignee: georg.brandl
components: Library (Lib)
messages: 124949
nosy: georg.brandl, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve webbrowser.open doc (and, someday, behavior?)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10799>
_______________________________________

From report at bugs.python.org  Fri Dec 31 05:03:40 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 31 Dec 2010 04:03:40 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293768220.01.0.058103996203.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Even after much uninstalling and reinstalling (and reboots) I never got TortoiseSVN to work properly, so I switched to TortoiseHg. The sources are now at:

    https://code.google.com/p/mrab-regex-hg/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 31 05:24:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 04:24:05 +0000
Subject: [issue6285] Silent abort on XP help document display
In-Reply-To: <1245022007.21.0.85627036232.issue6285@psf.upfronthosting.co.za>
Message-ID: <1293769445.05.0.607008696287.issue6285@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

webbrowser appears to be designed to return True/False if it does/or not open a browser window (regardless of site response). (I opened #10799 for a doc addition.) I believe an exception would likely indicate a bug therein. So I only wrapped the Windows startfile call (and only catch WindowsError), which could fail with any bad entry, and not just one left over from a previous install.

This patch should make the behavior on Windows much like on other systems: display message and move on. I have (yet) not tested this (but may try to), but take Scott's and Amaury's claims that the message call is correct. I will commit in a week if there are no objections.

----------
assignee:  -> terry.reedy
keywords: +patch
stage:  -> commit review
type:  -> behavior
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20199/z6285.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6285>
_______________________________________

From report at bugs.python.org  Fri Dec 31 05:45:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 04:45:55 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1293770755.99.0.332198588111.issue2710@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If there is no verification that there is a bug in 2.7/3.1,2, then I think this should be closed.

----------
nosy: +terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Fri Dec 31 06:01:12 2010
From: report at bugs.python.org (Xuanji Li)
Date: Fri, 31 Dec 2010 05:01:12 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1293771672.8.0.508036214914.issue10694@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Ok, new patch that creates a zipfile (actually I used TESTFN2, all the other tests seem to also use it)

----------
Added file: http://bugs.python.org/file20200/Issue10694_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Fri Dec 31 07:04:55 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 31 Dec 2010 06:04:55 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293775495.19.0.036771767196.issue7995@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch (the original one in patch form) against py3k with unit test.

It seems to work well - tested on Linux & FreeBSD.

----------
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20201/7995_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Fri Dec 31 08:00:41 2010
From: report at bugs.python.org (Xuanji Li)
Date: Fri, 31 Dec 2010 07:00:41 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1293778841.12.0.682028538196.issue10044@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

fwiw I've always found this helpful for undefined behavior: http://blog.regehr.org/archives/213 and, just as it says "x+1 > x" will be optimized to a nop, by the same logic "v >= &array[0] && v < &array[array_len]" will also be optimized to a nop.

----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Fri Dec 31 08:35:48 2010
From: report at bugs.python.org (bugs-python@vendor.thewrittenword.com)
Date: Fri, 31 Dec 2010 07:35:48 +0000
Subject: [issue10800] libffi build failure on HP-UX 11/PA
In-Reply-To: <1293780948.24.0.107395792812.issue10800@psf.upfronthosting.co.za>
Message-ID: <1293780948.24.0.107395792812.issue10800@psf.upfronthosting.co.za>


New submission from bugs-python at vendor.thewrittenword.com <bugs-python at vendor.thewrittenword.com>:

Python 3.1.3 fails to build on HP-UX/PA:
In file included from /opt/build/Python-3.1.3/Modules/_ctypes/libffi/src/dlmalloc.c:1156:
/opt/TWWfsw/gcc42/lib/gcc/hppa2.0-hp-hpux11.31/4.2/include/stdlib.h:577: error: redefinition of 'struct mallinfo'

Failed to build these modules:
_ctypes

<stdlib.h> on HP-UX has a conflicting definition for struct mallinfo:
#ifndef _STRUCT_MALLINFO
#  define _STRUCT_MALLINFO

  /* structure filled by mallinfo */
  struct mallinfo  {
        int32_t arena;          /* total number of bytes in arena */
        int32_t ordblks;        /* number of ordinary blocks */
        int32_t smblks;         /* number of small blocks */
        int32_t hblks;          /* number of holding blocks */
        int32_t hblkhd;         /* number of bytes in holding block headers */
        int32_t usmblks;        /* number of bytes in small blocks in use */
        int32_t fsmblks;        /* number of bytes in free small blocks */
        int32_t uordblks;       /* number of bytes in ordinary blocks in use */
        int32_t fordblks;       /* number of bytes in free ordinary blocks */
        int32_t keepcost;       /* cost of enabling keep option */
  };    
#endif /* _STRUCT_MALLINFO */

----------
assignee: theller
components: ctypes
messages: 124956
nosy: bugs-python at vendor.thewrittenword.com, theller
priority: normal
severity: normal
status: open
title: libffi build failure on HP-UX 11/PA
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10800>
_______________________________________

From report at bugs.python.org  Fri Dec 31 09:15:16 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 31 Dec 2010 08:15:16 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1293783316.33.0.448945196387.issue7322@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch which fixes the issue.

Instead of allowing the readline method to lose data, it adds a check to SocketIO.readinto() to ensure that the socket does not have a timeout and throws an IOError if it does. Also does the same for SocketIO.write().

I think this is a better approach - just failing immediately when a readline on a nonblocking socket occurs instead of failing sometimes and losing data.

----------
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file20202/7322_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Fri Dec 31 09:26:53 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 31 Dec 2010 08:26:53 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1293784013.86.0.829407056949.issue7322@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Fri Dec 31 10:14:55 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 31 Dec 2010 09:14:55 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293786895.46.0.209186756797.issue7995@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

issue1515839 seems to be a duplicate of this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Fri Dec 31 10:23:55 2010
From: report at bugs.python.org (Jacques Grove)
Date: Fri, 31 Dec 2010 09:23:55 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293787435.38.0.13483303013.issue2636@psf.upfronthosting.co.za>


Jacques Grove <aquarapid at gmail.com> added the comment:

Thanks for putting up the hg repo, makes it much easier to follow.

Getting back to the performance regression I reported in msg124904:

I've verified that if I take the hg commit 7abd9f9bb1 , and I back out the guards changes manually, while leaving the FAST_INIT changes in, the performance is back to normal on my full regression suite (i.e. the 30-40% penalty disappears).

I've repeated my tests a few times to make sure I'm not mistaken;  since the guard changes doesn't look like it should impact performance much, but it does.

I've attached the diff that restored the speed for me (as usual, using Python 2.6.5 on Linux x86_64)

BTW, now that we have the code on google code, can we log individual issues over there?  Might make it easier for those interested to follow certain issues than trying to comb through every individual detail in this super-issue-thread...?

----------
Added file: http://bugs.python.org/file20203/remove_guards.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 31 10:32:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 31 Dec 2010 09:32:03 +0000
Subject: [issue1515839] socket timeout inheritance on accept
Message-ID: <1293787923.38.0.183994405791.issue1515839@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem you have reported here was later independently reported in Issue7995 where a possible fix has been proposed.  Suggest adding yourself to the nosy list of that issue to monitor current status.

----------
nosy: +ned.deily
resolution:  -> duplicate
status: open -> closed
superseder:  -> On Mac / BSD sockets returned by accept inherit the parent's FD flags

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515839>
_______________________________________

From report at bugs.python.org  Fri Dec 31 11:38:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Dec 2010 10:38:53 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293754066.44.0.150961801844.issue6210@psf.upfronthosting.co.za>
Message-ID: <1293791928.3680.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 31 d?cembre 2010 ? 00:07 +0000, Patrick W. a ?crit :
> Patrick W. <poke at BornToLaugh.de> added the comment:
> 
> Antoine Pitrou (pitrou) at 2010-12-30 18:32 (UTC)
> > We are talking about context, not cause.
> 
> Yes, but - as said before - obviously the cause takes a higher
> precedence than context (otherwise it wouldn't show a context message
> when you explicitely set that). So when *explicitely* setting the
> cause to `None`, it should use the cause `None` and ignore the
> context, and as such display nothing.

It looks quite unintuitive to me, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Fri Dec 31 11:47:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Dec 2010 10:47:42 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1293792462.45.0.669939205018.issue7322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

While this patch looks conformant to the documentation, it is very likely to break code in the wild. Even in the stdlib, there are uses of makefile() + socket timeouts (e.g. in http.client and urllib). It would be better to find a way to make readline() functional even with socket timeouts.

----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Fri Dec 31 12:58:12 2010
From: report at bugs.python.org (Konstantin Osipov)
Date: Fri, 31 Dec 2010 11:58:12 +0000
Subject: [issue3766] socket.socket.recv broken (unbearably slow)
In-Reply-To: <1220479128.18.0.248146469424.issue3766@psf.upfronthosting.co.za>
Message-ID: <1293796692.25.0.742783860843.issue3766@psf.upfronthosting.co.za>


Konstantin Osipov <kostja.osipov at gmail.com> added the comment:

I was able to observe the same issue:

I'm using Python 2.6.5 on Ubuntu 10.0.4 LTS. My system is 64 bit Intel Core I7, Quad core, Linux kernel 2.6.32-generic x86_64, Ubuntu EGLIBC 2.11.1-0ubuntu7.5.

A simple client TCP socket, which sends 35 bytes over to a server on localhost and receives 20 bytes in response, produces only 22 RPS. An identical application written in C gives me 7000 RPS. TCP_NODELAY is on on the server side. Turning on TCP_NODELAY on the client gives me ~500 RPS in Python (which I'm satisfied with, 'cause I think I then hit other bottlenecks). 
Still, such low performance on by default can be surprising and hard to debug.

----------
nosy: +kostja

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3766>
_______________________________________

From report at bugs.python.org  Fri Dec 31 14:38:39 2010
From: report at bugs.python.org (M. Z.)
Date: Fri, 31 Dec 2010 13:38:39 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>


New submission from M. Z. <mzdkmail at gmail.com>:

Trying to unpack a ZIP file where some packet files contain danish letters results in:

    zipfile.BadZipFile: File name in directory 'filename_with_?o?.txt'
    and header b'filename_with_\x91o\x86.txt' differ.

Using Py 3.2b2 on Win7.

Unpack the attached ZIP file and run the Py script, which will show the problem using the enclosed two ZIP files.

----------
components: Library (Lib)
files: bug_zipfile_extractall.zip
messages: 124964
nosy: M..Z.
priority: normal
severity: normal
status: open
title: zipfile.ZipFile().extractall() header mismatch for non-ASCII characters
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20204/bug_zipfile_extractall.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Fri Dec 31 15:03:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Dec 2010 14:03:42 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293804222.8.0.677624491111.issue10801@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, haypo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Fri Dec 31 15:13:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Dec 2010 14:13:45 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293804825.08.0.723795220366.issue7995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. Comments/questions:
- please don't use C++-style comments ("//") in C code; some compilers can choke on them
- should the code path be also enabled for netbsd? (or other variants?)
- why does the test silence socket.error on accept()?
- what if fcntl() returns -1? (unlikely I know)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Fri Dec 31 15:26:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 31 Dec 2010 14:26:32 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293805592.4.0.338802600564.issue10801@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The attached patch fixes it for me. No time to write tests right now.

----------
keywords: +patch
Added file: http://bugs.python.org/file20205/zipfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Fri Dec 31 15:50:50 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 31 Dec 2010 14:50:50 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1293807050.86.0.598371803966.issue7995@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

>From what I coud see, the same applied to NetBSD so I enabled it for NetBSD as well - if there are any other OSes that need it enabled, they can be added.

The updated patch checks for fcntl() failing and simply leaves the socket as is if it fails.

The test silenced socket.error() just because the other tests did like testSetBlocking, testInitNonBlocking, testAccept, etc. I updated it to remove this.

----------
Added file: http://bugs.python.org/file20206/7995_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Fri Dec 31 16:42:51 2010
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Dec 2010 15:42:51 +0000
Subject: [issue6210] Exception Chaining missing method for suppressing context
In-Reply-To: <1293791928.3680.0.camel@localhost.localdomain>
Message-ID: <4D1DFA03.4040700@stoneleaf.us>


Ethan Furman <ethan at stoneleaf.us> added the comment:

raise AttributeError from None

makes sense to me, and in a nice, short example like that I prefer it. 
In real code, however, I think

raise AttributeError.no_context("Field %s is not in table" % attr)

is going to be easier for the human to parse than

raise AttributeError("Field %s is not in table" % attr) from None

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________

From report at bugs.python.org  Fri Dec 31 18:23:18 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 31 Dec 2010 17:23:18 +0000
Subject: [issue9361] Tests for leapdays in calendar.py module
In-Reply-To: <1279911522.69.0.474631084692.issue9361@psf.upfronthosting.co.za>
Message-ID: <1293816198.59.0.281323530047.issue9361@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I just tried John's patch, and:

- it still applies without problem (except for a bit of offset)
- I can confirm that it actually adds test coverage for leapdays() function (bringing calendar coverage from 71% to 72%).

I think it would be good to apply it to py3k branch.

Cheers,
Sandro

----------
nosy: +sandro.tosi
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9361>
_______________________________________

From report at bugs.python.org  Fri Dec 31 18:44:45 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 31 Dec 2010 17:44:45 +0000
Subject: [issue9370] Add reader redirect from test package docs to unittest
	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1293817485.97.0.780531085784.issue9370@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Nick,
the "See also" section already points to unittest module; are you asking to extend its description to mention that's the tool people should use for their unittest suites?

Cheers,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9370>
_______________________________________

From report at bugs.python.org  Fri Dec 31 18:55:19 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 31 Dec 2010 17:55:19 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1293818119.98.0.830939161252.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Why not? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Dec 31 20:02:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 31 Dec 2010 19:02:51 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1293822171.68.0.264681164841.issue1674555@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a proof of concept patch if anyone wants to play with it.    Note that a higher value could be used for the j option; multiple threads help even on uniprocessor systems since a bunch of the tests spend time waiting around.

The patch removes the '-l' option from the make test run.  I'm not sure that matters, since we do our best to fix memory leaks before shipping a release, and we don't use make test to do our leak testing (as far as I know).

I'm not sure this is an appropriate solution, so I won't apply this unless I get some favorable votes from committers and/or packagers. 

One interesting thing is that several additional tests show up as altering the execution environment when run this way.  That bears investigation at some point, but is an orthogonal issue.

As noted, test_trace does not pass, but only one test within it fails, so that ought to be easy enough to fix.  Also note that this "fix" would only be applicable to 3.2 and 2.7.

----------
keywords: +patch
nosy: +doko, loewis, pitrou
Added file: http://bugs.python.org/file20207/make_test_S.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Fri Dec 31 20:24:33 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 31 Dec 2010 19:24:33 +0000
Subject: [issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47
In-Reply-To: <1282668033.06.0.983312258691.issue9671@psf.upfronthosting.co.za>
Message-ID: <1293823473.77.0.561010712704.issue9671@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
I tried on a freshly build 2.7, and I can't replicate the reported error. Could it be it has been fixed by r78136?

Sridhar, are you still seeing this error?

Cheers,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9671>
_______________________________________

From report at bugs.python.org  Fri Dec 31 20:32:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 31 Dec 2010 19:32:44 +0000
Subject: [issue9361] Tests for leapdays in calendar.py module
In-Reply-To: <1279911522.69.0.474631084692.issue9361@psf.upfronthosting.co.za>
Message-ID: <1293823964.92.0.161322913635.issue9361@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied in r87590.  I threw in an extra test for a multi-leapyear-range.  Since there was no reason not to, I backported it to 3.1 in r87591 and 2.7 in r87592.  In the latter two commits I also backported the issue 9342 patch.

Thanks for the patch, John, and for the review, Sandro.

----------
nosy: +r.david.murray
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9361>
_______________________________________

From report at bugs.python.org  Fri Dec 31 20:34:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 31 Dec 2010 19:34:02 +0000
Subject: [issue9342] Tests for monthrange in calendar.py module
In-Reply-To: <1279887609.81.0.197947140036.issue9342@psf.upfronthosting.co.za>
Message-ID: <1293824042.44.0.155008833056.issue9342@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Backported it to 3.1 in r87591 and 2.7 in r87592 along with the patch for issue 9361.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9342>
_______________________________________

From report at bugs.python.org  Fri Dec 31 20:35:27 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 31 Dec 2010 19:35:27 +0000
Subject: [issue10270] Fix resource warnings in test_threading
In-Reply-To: <1288549842.1.0.819549161722.issue10270@psf.upfronthosting.co.za>
Message-ID: <1293824127.09.0.994616242649.issue10270@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Already fixed in r86107

----------
nosy: +sandro.tosi
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10270>
_______________________________________

From report at bugs.python.org  Fri Dec 31 21:56:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 31 Dec 2010 20:56:10 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1293828970.41.0.769168103434.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I finally got around to researching this issue in the tracker.

Issue 10298 is a close relative to this issue.  The fix from that issue make the test that Xuanji added here pass.  That issue contains no tests....it would be ideal to have tests that test the behavior in the face of actual comments in the zipfile, but even if all we have is Xuanji's test IMO we should apply one of the two fixes.

The 10298 patch takes the approach of ignoring the excess data but preserving the comment if any.  The author implies that that is what other tools do, so in the absence of input from Alan or other zipfile experts that's probably what we should go with.

Rep, could you look over this issue and indicate if you agree?

Note also issue 9239, which fixes one way that zipfile could create a zipfile with garbage at the end.

Then there is issue 1757072, where we hear some of Alan's thinking about this: a "non-strict" mode...but it is perhaps too late for a feature request, and there is the fact that ignoring the trailing data appears to be a de-facto standard.

And then we have issue 1757072, which is identical to this one and was closed won't fix, but apparently only because the source of the corrupted zip files wasn't identified, which this issue does do.

Interestingly, issue 669036 claims that zipfile.py supports garbage at the start, which makes tolerating garbage at the end seem sensibly symmetric.

Finally, comment support was added by the patch in issue 611760.  It would be interesting to know if garbage at the end was supported before that patch.  My guess is that it was, by ignoring it, but I haven't tested it.

Summary: if someone can review the actual patch, I think we should apply the issue 10298 patch along with Xuanji's test.  Xuanji, if you have the time and desire to add some additional tests that test comments with trailing data, that would be a bonus.  You could look at the tests in issue 9239 for ideas.

----------
nosy: +rep, rfk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10694>
_______________________________________

From report at bugs.python.org  Fri Dec 31 22:34:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 31 Dec 2010 21:34:05 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1293831245.92.0.3580256352.issue10801@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FWIW, having just looked at related code in zipfile recently, this patch looks correct to me.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Fri Dec 31 23:33:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 22:33:06 +0000
Subject: [issue10771] descriptor protocol documentation has two different
	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293834786.62.0.332615857223.issue10771@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For future reference, the 'trunk' branch was frozen with the release of 2.7 in June 2010. However, this particular text is unchanged since in 2.7.1 and still in 3.2b2 (except for removal of 'new style'.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10771>
_______________________________________

From report at bugs.python.org  Fri Dec 31 23:35:16 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 22:35:16 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1293834916.02.0.684523064407.issue10772@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bethard
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Fri Dec 31 23:41:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 22:41:48 +0000
Subject: [issue10782] Not possible to cross-compile due to poor detection of
	%lld support in printf
In-Reply-To: <1293473376.4.0.265613686073.issue10782@psf.upfronthosting.co.za>
Message-ID: <1293835308.72.0.0592009849702.issue10782@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Requests for information should go to python-list or other support forums. That said, does the response settle this issue, so that it can be closed, or is there still a claim that something should be changed in the Python repository?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10782>
_______________________________________